FTW(3P)

πŸ’– FTW(3P) β€” bestie's guide to walking file trees πŸ’–

okay so first things first: this is a page from the POSIX Programmer's Manual (yes, that manual, the fancy standards one, not the Linux one). Heads up tho β€” the Linux implementation of this interface may be different from what's written here, so go peek at the corresponding Linux manual page for the deets on Linux behavior. or like. it might not even be implemented on Linux at all. πŸ™ˆ vibe check accordingly.


✨ NAME ✨

ftw β€” traverse (walk) a file tree πŸŒ³πŸšΆβ™€οΈ


πŸŽ€ SYNOPSIS πŸŽ€

#include <ftw.h>

int ftw(const char *path, int (*fn)(const char *,
    const struct stat *ptr, int flag), int ndirs);

πŸ¦‹ DESCRIPTION πŸ¦‹

So ftw() literally just descends the directory hierarchy rooted at path, recursively, like a lil explorer. For every single object it finds in that hierarchy, ftw() calls the function that fn points to. And what does it hand over? A pointer to a null-terminated character string with the object's name, plus a pointer to a stat structure stuffed with info about that object β€” filled in as if stat() or lstat() had been called to grab it. cute right?

The possible values of that integer, which are defined in the <ftw.h> header, are:

  • FTW_D β€” it's a directory πŸ“
  • FTW_DNR β€” it's a directory that cannot be read 😭
  • FTW_F β€” it's a non-directory file πŸ“„
  • FTW_SL β€” it's a symbolic link (but also go read FTW_NS below, ok?)
  • FTW_NS β€” an object other than a symbolic link on which stat() could not successfully be executed. and if the object is a symbolic link and stat() failed? then it is unspecified whether ftw() passes FTW_SL or FTW_NS to the user-supplied function. mystery behavior, we love a plot twist πŸ’€

If that integer is FTW_DNR, then the descendants of that directory shall not be processed. gone. not happening. and if the integer is FTW_NS, the stat structure contains undefined values β€” so like, don't trust it bestie. An example of an object that would cause FTW_NS to get passed to the function pointed to by fn would be a file in a directory with read but without execute (search) permission.

ftw() shall visit a directory before visiting any of its descendants. parent first, always. main character energy πŸ‘‘

ftw() shall use at most one file descriptor for each level in the tree.

The argument ndirs should be in the range [1,{OPEN_MAX}].

The tree traversal shall continue until either the tree is exhausted, an invocation of fn returns a non-zero value, or some error other than [EACCES] is detected within ftw().

The ndirs argument shall specify the max number of directory streams, file descriptors, or both, available for ftw() to use while it's traversing the tree. and when ftw() returns, it shall close any directory streams and file descriptors it used β€” not counting any that the application-supplied fn function opened. those are yours, boo.

The results are unspecified if the application-supplied fn function does not preserve the current working directory. so like. don't touch the cwd. fr fr.

Also ftw() need not be thread-safe. so maybe don't invite it to the group chat with multiple threads at once 🫢


🌈 RETURN VALUE 🌈

  • If the tree is exhausted, ftw() shall return 0. slay.
  • If the function pointed to by fn returns a non-zero value, ftw() shall stop its tree traversal and return whatever value was returned by the function pointed to by fn. it respects your choices πŸ’…
  • If ftw() detects an error, it shall return -1 and set errno to indicate the error.

If ftw() encounters an error other than [EACCES] (see FTW_DNR and FTW_NS above), it shall return -1 and set errno to indicate the error. The external variable errno may contain any error value that is possible when a directory is opened or when one of the stat functions is executed on a directory or file.


⭐ ERRORS ⭐

The ftw() function shall fail if:

  • EACCES β€” Search permission is denied for any component of path, or read permission is denied for path.
  • ELOOP β€” A loop exists in symbolic links encountered during resolution of the path argument.
  • ENAMETOOLONG β€” The length of a component of a pathname is longer than {NAME_MAX}.
  • ENOENT β€” A component of path does not name an existing file, or path is an empty string.
  • ENOTDIR β€” A component of path names an existing file that is neither a directory nor a symbolic link to a directory.
  • EOVERFLOW β€” A field in the stat structure cannot be represented correctly in the current programming environment for one or more files found in the file hierarchy.

The ftw() function may fail if:

  • EINVAL β€” The value of the ndirs argument is invalid.
  • ELOOP β€” More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the path argument.
  • ENAMETOOLONG β€” The length of a pathname exceeds {PATH_MAX}, or pathname resolution of a symbolic link produced an intermediate result with a length that exceeds {PATH_MAX}.

In addition, if the function pointed to by fn encounters system errors, errno may be set accordingly. iykyk.

The following sections are informative. (translation: the real ones are done, these are the bonus content πŸ’œ)

🌸 EXAMPLES 🌸

🧚 Walking a Directory Structure

The following example walks the current directory structure, calling the fn function for every directory entry, using at most 10 file descriptors:

#include <ftw.h>
...
if (ftw(".", fn, 10) != 0) {
    perror("ftw"); exit(2);
}

πŸ“ APPLICATION USAGE πŸ“

The ftw() function may allocate dynamic storage while it's doing its thing. And if ftw() gets forcibly terminated β€” like, say, by longjmp() or siglongjmp() being executed by the function pointed to by fn, or by an interrupt routine β€” then ftw() never gets a chance to free that storage, so it remains permanently allocated. 😭 leaked forever. gone but not forgotten.

A safe way to handle interrupts is to store the fact that an interrupt has occurred, and arrange to have the function pointed to by fn return a non-zero value at its next invocation. do that instead. please.

Applications should use the nftw() function instead of the obsolescent ftw() function. yeah bestie ftw() is giving deprecated-era vibes πŸ’€

πŸ‘‘ RATIONALE πŸ‘‘

None. literally none. nothing to see here πŸŽ€


πŸ’€ FUTURE DIRECTIONS πŸ’€

The ftw() function may be removed in a future version. so like. plan accordingly.


πŸ”₯ SEE ALSO πŸ”₯

fdopendir(), fstatat(), longjmp(), nftw(), siglongjmp()

The Base Definitions volume of POSIX.1‐2017, <ftw.h>, <sys_stat.h>


Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .


okay that's the whole page bestie, you ate that πŸ’… this lil masterpiece was served up by IEEE/The Open Group back in 2017 (that's the source + version + date, all folded into this cute sign-off 🫢✨). now go walk some trees responsibly. πŸŒ³πŸ’–

πŸ“¦ where this page comes from