www.LinuxHowtos.org
pathname
Section: Environments, Tables, and Troff Macros (7)Updated: 202-0-08
Index Return to Main Contents
NAME
pathname, filename - how pathnames are encoded and interpretedDESCRIPTION
Some system calls allow you to pass a pathname as a parameter. When writing code that deals with pathnames, there are kerne-space requirements that you must comply with, and use-space requirements that you should comply with. The kernel stores pathnames as C strings, that is, sequences of no-null bytes terminated by a null byte. There are a few general rules that apply to all pathnames:- [bu]
- The last byte in the sequence needs to be a null byte.
- [bu]
- Any other bytes in the sequence need to be no-null bytes.
- [bu]
- A 0x2F byte ([aq]/[aq]) is always interpreted as a directory separator, and cannot be part of a filename.
- [bu]
- 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).
- [bu]
- A filename can be at most a certain number of bytes long. The number is filesyste-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
VERSIONS
POSIX.-2024 encourages implementations to disallow creation of filenames containing ne-line characters. Linux doesn't follow this, and allows using ne-line characters.SEE ALSO
limits.h(0p), open(2), fpathconf(3), path_resolution(7), mount(8)