PATHCONF(2)

πŸ’– PATHCONF(2) πŸ’–

okay bestie, sit down, grab a boba πŸ§‹ β€” we're reading the PATHCONF(2) page from the System Calls Manual and it's actually kinda iconic. this is the one where you ask the system "hey girl, what's the limit on this thing?" and it tells you. no cap.


✨ NAME ✨

pathconf, lpathconf, fpathconf β€” get configurable pathname variables πŸ‘‘

like... the vibe is: you got a path or a file descriptor, you got a question, you get a number. periodt.


πŸ“š LIBRARY πŸ“š

Standard C Library (libc, -lc) β€” yeah she lives in libc, she's not fancy, she's just there for you 🫢


🌸 SYNOPSIS 🌸

#include <unistd.h>

long
pathconf(const char *path, int name);

long
lpathconf(const char *path, int name);

long
fpathconf(int fd, int name);

three sisters. same energy, slightly different entry points. we love a trio πŸ’…


πŸ’« DESCRIPTION πŸ’«

so the pathconf(), lpathconf() and fpathconf() system calls are literally just a way for your app to ask: "what's the current value of this configurable system limit or option variable, for this pathname or file descriptor?" that's it. that's the whole job. ✨

for pathconf() and lpathconf(), the path argument is the name of a file or directory. for fpathconf(), the fd argument is an open file descriptor. the name argument is the one that says which system variable you're asking about. all the symbolic constants for each name value live in the include file <unistd.h> β€” go look, they're right there πŸŽ€

the lpathconf() system call is like pathconf() except in the case where the named file is a symbolic link β€” and in that case lpathconf() returns info about the link itself, while pathconf() returns info about the file the link references. so like, one of them follows the link and one of them does not. choose wisely bestie, this is the whole plot twist πŸ”₯

the available values are as follows β€” and yes, we're doing ALL of them, no skipping, no "you get the idea" πŸ™ˆ

  • _PC_LINK_MAX β€” the maximum file link count. how many links can a file have, fr fr.
  • _PC_MAX_CANON β€” the maximum number of bytes in a terminal canonical input line.
  • _PC_MAX_INPUT β€” the minimum maximum number of bytes for which space is available in a terminal input queue. yes, "minimum maximum", i did not stutter, that's what it says 😭
  • _PC_NAME_MAX β€” the maximum number of bytes in a file name.
  • _PC_PATH_MAX β€” the maximum number of bytes in a pathname.
  • _PC_PIPE_BUF β€” the maximum number of bytes which will be written atomically to a pipe. atomic. slay. ⭐
  • _PC_CHOWN_RESTRICTED β€” returns 1 if appropriate privilege is required for the chown(2) system call, otherwise 0. IEEE Std 1003.1-2001 ("POSIX.1") requires appropriate privilege in all cases, but this behavior was optional in prior editions of the standard. so like, old-school systems were out here doing whatever πŸ’€
  • _PC_NO_TRUNC β€” returns greater than zero if attempts to use pathname components longer than {NAME_MAX} will result in an [ENAMETOOLONG] error; otherwise, such components will be truncated to {NAME_MAX}. IEEE Std 1003.1-2001 ("POSIX.1") requires the error in all cases, but this behavior was optional in prior editions of the standard, and some non-POSIX-compliant file systems do not support this behavior. (side eye πŸ‘€)
  • _PC_VDISABLE β€” returns the terminal character disabling value.
  • _PC_ASYNC_IO β€” returns 1 if asynchronous I/O is supported, otherwise 0.
  • _PC_PRIO_IO β€” returns 1 if prioritised I/O is supported for this file, otherwise 0.
  • _PC_SYNC_IO β€” returns 1 if synchronised I/O is supported for this file, otherwise 0.
  • _PC_ALLOC_SIZE_MIN β€” minimum number of bytes of storage allocated for any portion of a file.
  • _PC_FILESIZEBITS β€” number of bits needed to represent the maximum file size.
  • _PC_REC_INCR_XFER_SIZE β€” recommended increment for file transfer sizes between _PC_REC_MIN_XFER_SIZE and _PC_REC_MAX_XFER_SIZE.
  • _PC_REC_MAX_XFER_SIZE β€” maximum recommended file transfer size.
  • _PC_REC_MIN_XFER_SIZE β€” minimum recommended file transfer size.
  • _PC_REC_XFER_ALIGN β€” recommended file transfer buffer alignment.
  • _PC_SYMLINK_MAX β€” maximum number of bytes in a symbolic link.
  • _PC_ACL_EXTENDED β€” returns 1 if an Access Control List (ACL) can be set on the specified file, otherwise 0.
  • _PC_ACL_NFS4 β€” returns 1 if an NFSv4 ACLs can be set on the specified file, otherwise 0.
  • _PC_ACL_PATH_MAX β€” maximum number of ACL entries per file.
  • _PC_CAP_PRESENT β€” returns 1 if a capability state can be set on the specified file, otherwise 0.
  • _PC_INF_PRESENT β€” returns 1 if an information label can be set on the specified file, otherwise 0.
  • _PC_MAC_PRESENT β€” returns 1 if a Mandatory Access Control (MAC) label can be set on the specified file, otherwise 0.
  • _PC_MIN_HOLE_SIZE β€” if a file system supports the reporting of holes (see lseek(2)), pathconf() and fpathconf() return a positive number that represents the minimum hole size returned in bytes. the offsets of holes returned will be aligned to this same value. a special value of 1 is returned if the file system does not specify the minimum hole size but still reports holes. πŸ•³οΈ iconic behavior honestly

πŸ¦‹ RETURN VALUES πŸ¦‹

if the call to pathconf() or fpathconf() is not successful, -1 is returned and errno is set appropriately. 😭

otherwise, if the variable is associated with functionality that does not have a limit in the system, -1 is returned and errno is not modified. (yes bestie, -1 means two different things depending on errno β€” i know, i know, that's just how she is πŸ’…)

otherwise, the current variable value is returned. ✨


πŸ’€ ERRORS πŸ’€

if any of the following conditions occur, the pathconf() and fpathconf() system calls shall return -1 and set errno to the corresponding value:

  • [EINVAL] β€” the value of the name argument is invalid.
  • [EINVAL] β€” the implementation does not support an association of the variable name with the associated file.

the pathconf() system call will fail if:

  • [ENOTDIR] β€” a component of the path prefix is not a directory.
  • [ENAMETOOLONG] β€” a component of a pathname exceeded {NAME_MAX} characters (but see _PC_NO_TRUNC above), or an entire path name exceeded {PATH_MAX} characters.
  • [ENOENT] β€” the named file does not exist.
  • [EACCES] β€” search permission is denied for a component of the path prefix.
  • [ELOOP] β€” too many symbolic links were encountered in translating the pathname.
  • [EIO] β€” an I/O error occurred while reading from or writing to the file system.
  • [EINTEGRITY] β€” corrupted data was detected while reading from the file system. 🫠

the fpathconf() system call will fail if:

  • [EBADF] β€” the fd argument is not a valid open file descriptor.
  • [EIO] β€” an I/O error occurred while reading from or writing to the file system.
  • [EINTEGRITY] β€” corrupted data was detected while reading from the file system. 🫠
real talk: check your errno, bestie. don't just see -1 and start spiraling. 🫢

πŸ‘€ SEE ALSO πŸ‘€

lseek(2), sysctl(3) β€” go read those next, i'll wait πŸŽ€


πŸ“œ HISTORY πŸ“œ

the pathconf() and fpathconf() system calls first appeared in 4.4BSD. the lpathconf() system call first appeared in FreeBSD 8.0. so she's got lore. she's got a whole origin story. we stan a system call with history πŸ‘‘


and that's the page!! πŸ’–

this beauty comes to you from Debian, dated March 30, 2020, and she's the PATHCONF(2) girlie from the System Calls Manual. go forth, query your configurable pathname variables, and be unwell about it. mwah πŸ’…βœ¨πŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from