NAME¶

pathname, filename - how pathnames are encoded and interpreted

DESCRIPTION¶

Some system calls allow you to pass a pathname as a parameter. When writing code that deals with pathnames, there are kernel-space requirements that you must comply with, and user-space requirements that you should comply with.

The kernel stores pathnames as C strings, that is, sequences of non-null bytes terminated by a null byte. There are a few general rules that apply to all pathnames:

•

The last byte in the sequence needs to be a null byte.

•

Any other bytes in the sequence need to be non-null bytes.

•

A 0x2F byte ('/') is always interpreted as a directory separator, and cannot be part of a filename.

•

A pathname can be at most PATH_MAX bytes long (see limits.h(0p)). A pathname that's longer than PATH_MAX bytes can be split into multiple smaller pathnames and opened piecewise using openat(2).

•

A filename can be at most a certain number of bytes long. The number is filesystem-specific (see _PC_NAME_MAX in fpathconf(3)). For maximum portability, programs should be able to handle filenames that are as long as the relevant filesystems will allow. For maximum portability, programs and users should limit the length of their own pathnames to NAME_MAX bytes (see limits.h(0p)).

Some filesystems or APIs may apply further restrictions, such as requiring shorter filenames, or restricting the allowed bytes in a filename.

For maximum interoperability, programs and users should also limit the characters that they use for their own pathnames to characters in the POSIX Portable Filename Character Set.

SEE ALSO¶

limits.h(0p), open(2), fpathconf(3), path_resolution(7), mount(8)