PATH_MAX Is Tricky
&gt; The problem is that you can’t meaningfully define a constant like this in a header file. The maximum path size is actually to be something like a filesystem limitation, or at the very least a kernel parameter.<p>AFAIK, &quot;paths&quot; aren&#x27;t a thing filesystems think about. As far as a filesystem driver is concerned, paths are either—for open&#x2F;read&#x2F;write&#x2F;etc.—plain inodes (a uint64), or—for directory-manipulation calls—an inode plus a ptrdiff_t to index into the dirent list†. The only things that care about NAME_MAX are lookup(2) [get inode given {inode, dirent}], and link(2) [put inode in {inode, dirent}].<p>So it&#x27;s really only the kernel, through its syscall interface, that cares about paths—and so PATH_MAX is just a representation of the maximum size of a path the kernel is willing to accept in those syscalls. As if they each had a statically-allocated path[PATH_MAX] buffer your path got copied into.<p>† Writing a FUSE filesystem is a great way to learn about what the kernel thinks a filesystem is. It&#x27;s very different from the userland perspective. For example, from a filesystem driver&#x27;s perspective, &quot;file descriptors&quot; don&#x27;t exist! Instead, read(2) and write(2) calls are stateless, each call getting passed a kernel-side io-handle struct that must get re-evaluated for matching permissions on each IO operation. (You can do <i>some</i> up-front evaluation during the open(2) call, but, given that a file&#x27;s permissions might <i>change</i> while you have a descriptor open to it, there&#x27;s not much point.)