1

The linux kernel defines PATH_MAX and NAME_MAX in limits.conf.

What would happen if I increase those constants and recompile the kernel?

Also, I believe I would have to change it in /usr/include/linux/limits.h and recompile libc (and any program that includes the header).

  1. Would I be able to create files with longer paths/names?
  2. What would happen if I mount a filesystem with those long filenames on another system?

For question 2: I know the kernel will keep you from creating files where the path is more than PATH_MAX. However, I wonder how it handles when the filesystem itself is providing it with a path longer than that (e.g. after an ls).

teapot
  • 19

1 Answers1

2

  1. It is already possible to create files with longer paths. By using relative paths, changing mount points etc. you can create files with absolute paths longer than PATH_MAX, and the kernel already knows how to deal with that. Increasing PATH_MAX (in include/uapi/linux/limits.h, not limits.conf) will increase the maximum path length you can process at a time. The Hurd famously doesn’t even define PATH_MAX.

    Increasing NAME_MAX won’t necessarily help much because you’ll run into file system limitations; most file systems in use on Linux support 255-byte component names only.

  2. As mentioned above, longer paths are already a fact of life, and Unix-style systems cope with them (using relative paths, symlinks etc.). Longer names can also occur, and calls such as readdir are documented as capable of returning names longer than the expected maximum.

See also To what extent does Linux support file names longer than 255 bytes?

Note too that programs shouldn’t use the build-time constants from limits.h, they should query limits using pathconf. Unfortunately that’s not always the case, and there’s a good chance you’d run into issues with a kernel assuming larger values of PATH_MAX and NAME_MAX when writing to buffers provided by userspace programs without a specified length.

Stephen Kitt
  • 434,908