6

In limits.h, and in various places in the POSIX manpages, there are references to PATH_MAX and NAME_MAX. How do these relate to one another? Where is the official documentation for them? How can I obtain them at run time, and (where relevant) compile time for the C, Python, and GNU (shell) environments?

Matt Joiner
  • 112,946
  • 110
  • 377
  • 526

1 Answers1

7

PATH_MAX is the maximum length of a filesystem path. NAME_MAX is the maximum length of a filename (in a particular spot). So, /foo/bar is restricted by PATH_MAX, and only the bar portion has its length limited by NAME_MAX.

You can get these at run time via pathconf, as _PC_PATH_MAX and _PC_NAME_MAX, although standard practice is generally just to use the static macros at compile time. I suppose it would be better to use the run-time option because you could potentially support longer values that way, but I'm not sure what (if any) systems actually provide a return from pathconf which is greater than the value of the POSIX_FOO_MAX values.

Borealid
  • 95,191
  • 9
  • 106
  • 122
  • Can you comment on whether or not they're available in Python, and where? – Matt Joiner Jul 24 '10 at 15:48
  • @Matt Joiner: Your question only really makes sense for C; there is no "compile time" for Python or shell scripting. If you are using a scripting language, these variables are also unlikely to be useful to you - just use an indefinite-length string to manipulate your paths. Also, these are system-specific variables, and a Python script should ideally be portable, so you may not want to make use of them and instead just check for "path too long" errors when creating/accessing a file. – Borealid Jul 24 '10 at 16:36
  • 2
    I'm writing a filesystem in Python, so they are in fact of great interest. I'm calling `os.fpathconf` on my device file as a best guess for `PATH_MAX`, and `NAME_MAX` is a property of my implementation returned through `struct statvfs`. Despite missing the Python tips this is a good answer. – Matt Joiner Jul 25 '10 at 02:21
  • Most operating systems support execution of code compiled on an earlier version of the OS (or even on a different OS altogether). Should one of these values change during an OS update, calling `pathconf` in runtime gives you the correct (updated) value for the kernel/libc you're running on, vs. the incorrect (obsolete) value for the kernel/libc you compiled on. Obviously it's superficially preferable to recompile for a new runtime, but that's not always possible or desirable in a specific instance. – dgc Sep 03 '18 at 17:56
  • 1
    Looks like POSIX actively forbids path components longer than `NAME_MAX`: pubs.opengroup.org/onlinepubs/9699919799/basedefs/… : "If any pathname component is longer than {NAME_MAX}, the implementation shall consider this an error." – Petr Skocik Oct 14 '20 at 21:29