1fts(3)                     Library Functions Manual                     fts(3)
2
3
4

NAME

6       fts,  fts_open, fts_read, fts_children, fts_set, fts_close - traverse a
7       file hierarchy
8

LIBRARY

10       Standard C library (libc, -lc)
11

SYNOPSIS

13       #include <sys/types.h>
14       #include <sys/stat.h>
15       #include <fts.h>
16
17       FTS *fts_open(char * const *path_argv, int options,
18                     int (*compar)(const FTSENT **, const FTSENT **));
19
20       FTSENT *fts_read(FTS *ftsp);
21
22       FTSENT *fts_children(FTS *ftsp, int instr);
23
24       int fts_set(FTS *ftsp, FTSENT *f, int instr);
25
26       int fts_close(FTS *ftsp);
27

DESCRIPTION

29       The fts functions are provided for traversing file hierarchies.  A sim‐
30       ple  overview  is  that  the fts_open() function returns a "handle" (of
31       type FTS *) that refers to a file hierarchy "stream".  This  handle  is
32       then  supplied to the other fts functions.  The function fts_read() re‐
33       turns a pointer to a structure describing one of the files in the  file
34       hierarchy.   The  function fts_children() returns a pointer to a linked
35       list of structures, each of which describes one of the files  contained
36       in a directory in the hierarchy.
37
38       In  general, directories are visited two distinguishable times; in pre‐
39       order (before any of their descendants are visited)  and  in  postorder
40       (after  all of their descendants have been visited).  Files are visited
41       once.  It is possible to walk the hierarchy "logically"  (visiting  the
42       files  that  symbolic  links point to) or physically (visiting the sym‐
43       bolic links themselves), order the  walk  of  the  hierarchy  or  prune
44       and/or revisit portions of the hierarchy.
45
46       Two  structures  (and associated types) are defined in the include file
47       <fts.h>.  The first type is FTS, the structure that represents the file
48       hierarchy itself.  The second type is FTSENT, the structure that repre‐
49       sents a file in the file hierarchy.  Normally, an FTSENT  structure  is
50       returned  for  every  file in the file hierarchy.  In this manual page,
51       "file" and "FTSENT structure" are generally interchangeable.
52
53       The FTSENT structure contains fields describing a file.  The  structure
54       contains  at  least  the  following fields (there are additional fields
55       that should be considered private to the implementation):
56
57           typedef struct _ftsent {
58               unsigned short  fts_info;     /* flags for FTSENT structure */
59               char           *fts_accpath;  /* access path */
60               char           *fts_path;     /* root path */
61               short           fts_pathlen;  /* strlen(fts_path) +
62                                                strlen(fts_name) */
63               char           *fts_name;     /* filename */
64               short           fts_namelen;  /* strlen(fts_name) */
65               short           fts_level;    /* depth (-1 to N) */
66               int             fts_errno;    /* file errno */
67               long            fts_number;   /* local numeric value */
68               void           *fts_pointer;  /* local address value */
69               struct _ftsent *fts_parent;   /* parent directory */
70               struct _ftsent *fts_link;     /* next file structure */
71               struct _ftsent *fts_cycle;    /* cycle structure */
72               struct stat    *fts_statp;    /* [l]stat(2) information */
73           } FTSENT;
74
75       These fields are defined as follows:
76
77       fts_info
78              One of the  following  values  describing  the  returned  FTSENT
79              structure and the file it represents.  With the exception of di‐
80              rectories without errors (FTS_D), all of these entries are  ter‐
81              minal,  that  is,  they  will  not be revisited, nor will any of
82              their descendants be visited.
83
84              FTS_D  A directory being visited in preorder.
85
86              FTS_DC A directory that  causes  a  cycle  in  the  tree.   (The
87                     fts_cycle field of the FTSENT structure will be filled in
88                     as well.)
89
90              FTS_DEFAULT
91                     Any FTSENT structure that represents a file type not  ex‐
92                     plicitly described by one of the other fts_info values.
93
94              FTS_DNR
95                     A  directory  which cannot be read.  This is an error re‐
96                     turn, and the fts_errno field will  be  set  to  indicate
97                     what caused the error.
98
99              FTS_DOT
100                     A  file  named "."  or ".."  which was not specified as a
101                     filename to fts_open() (see FTS_SEEDOT).
102
103              FTS_DP A directory being visited in postorder.  The contents  of
104                     the  FTSENT  structure will be unchanged from when it was
105                     returned in preorder, that is, with  the  fts_info  field
106                     set to FTS_D.
107
108              FTS_ERR
109                     This  is an error return, and the fts_errno field will be
110                     set to indicate what caused the error.
111
112              FTS_F  A regular file.
113
114              FTS_NS A file for which no [l]stat(2) information was available.
115                     The  contents of the fts_statp field are undefined.  This
116                     is an error return, and the fts_errno field will  be  set
117                     to indicate what caused the error.
118
119              FTS_NSOK
120                     A file for which no [l]stat(2) information was requested.
121                     The contents of the fts_statp field are undefined.
122
123              FTS_SL A symbolic link.
124
125              FTS_SLNONE
126                     A symbolic link with a nonexistent target.  The  contents
127                     of  the fts_statp field reference the file characteristic
128                     information for the symbolic link itself.
129
130       fts_accpath
131              A path for accessing the file from the current directory.
132
133       fts_path
134              The path for the file relative to the  root  of  the  traversal.
135              This path contains the path specified to fts_open() as a prefix.
136
137       fts_pathlen
138              The sum of the lengths of the strings referenced by fts_path and
139              fts_name.
140
141       fts_name
142              The name of the file.
143
144       fts_namelen
145              The length of the string referenced by fts_name.
146
147       fts_level
148              The depth of the traversal, numbered from -1 to  N,  where  this
149              file was found.  The FTSENT structure representing the parent of
150              the starting point (or root) of the traversal  is  numbered  -1,
151              and the FTSENT structure for the root itself is numbered 0.
152
153       fts_errno
154              If  fts_children()  or  fts_read()  returns  an FTSENT structure
155              whose fts_info field is set to FTS_DNR, FTS_ERR, or FTS_NS,  the
156              fts_errno  field  contains  the  error  number  (i.e., the errno
157              value) specifying the cause of the error.  Otherwise,  the  con‐
158              tents of the fts_errno field are undefined.
159
160       fts_number
161              This  field  is  provided for the use of the application program
162              and is not modified by the fts functions.  It is initialized  to
163              0.
164
165       fts_pointer
166              This  field  is  provided for the use of the application program
167              and is not modified by the fts functions.  It is initialized  to
168              NULL.
169
170       fts_parent
171              A  pointer  to  the FTSENT structure referencing the file in the
172              hierarchy immediately above the current file, that is,  the  di‐
173              rectory  of which this file is a member.  A parent structure for
174              the initial entry point is provided as well, however,  only  the
175              fts_level,  fts_number, and fts_pointer fields are guaranteed to
176              be initialized.
177
178       fts_link
179              Upon return from the fts_children() function, the fts_link field
180              points  to the next structure in the NULL-terminated linked list
181              of directory members.  Otherwise, the contents of  the  fts_link
182              field are undefined.
183
184       fts_cycle
185              If a directory causes a cycle in the hierarchy (see FTS_DC), ei‐
186              ther because of a hard link between two directories, or  a  sym‐
187              bolic  link  pointing to a directory, the fts_cycle field of the
188              structure will point to the FTSENT structure  in  the  hierarchy
189              that  references  the same file as the current FTSENT structure.
190              Otherwise, the contents of the fts_cycle field are undefined.
191
192       fts_statp
193              A pointer to [l]stat(2) information for the file.
194
195       A single buffer is used for all of the paths of all of the files in the
196       file  hierarchy.   Therefore,  the  fts_path and fts_accpath fields are
197       guaranteed to be null-terminated only for the file  most  recently  re‐
198       turned  by fts_read().  To use these fields to reference any files rep‐
199       resented by other FTSENT structures will require that the  path  buffer
200       be  modified using the information contained in that FTSENT structure's
201       fts_pathlen field.  Any such modifications should be undone before fur‐
202       ther  calls  to fts_read() are attempted.  The fts_name field is always
203       null-terminated.
204
205   fts_open()
206       The fts_open() function takes a pointer to an array of character point‐
207       ers  naming one or more paths which make up a logical file hierarchy to
208       be traversed.  The array must be terminated by a null pointer.
209
210       There are a number of options, at least one of which (either  FTS_LOGI‐
211       CAL  or  FTS_PHYSICAL)  must be specified.  The options are selected by
212       ORing the following values:
213
214       FTS_LOGICAL
215              This option causes the fts routines to return FTSENT  structures
216              for  the targets of symbolic links instead of the symbolic links
217              themselves.  If this option is set, the only symbolic links  for
218              which  FTSENT  structures  are  returned  to the application are
219              those referencing nonexistent files: the fts_statp field is  ob‐
220              tained via stat(2) with a fallback to lstat(2).
221
222       FTS_PHYSICAL
223              This  option causes the fts routines to return FTSENT structures
224              for symbolic links themselves instead of the target  files  they
225              point to.  If this option is set, FTSENT structures for all sym‐
226              bolic links in the hierarchy are returned  to  the  application:
227              the fts_statp field is obtained via lstat(2).
228
229       FTS_COMFOLLOW
230              This option causes any symbolic link specified as a root path to
231              be followed immediately, as if via  FTS_LOGICAL,  regardless  of
232              the primary mode.
233
234       FTS_NOCHDIR
235              As a performance optimization, the fts functions change directo‐
236              ries as they walk the file hierarchy.  This has the  side-effect
237              that  an  application cannot rely on being in any particular di‐
238              rectory during the traversal.  This option turns off this  opti‐
239              mization,  and the fts functions will not change the current di‐
240              rectory.  Note that applications should  not  themselves  change
241              their   current   directory  and  try  to  access  files  unless
242              FTS_NOCHDIR is specified and absolute pathnames were provided as
243              arguments to fts_open().
244
245       FTS_NOSTAT
246              By default, returned FTSENT structures reference file character‐
247              istic information (the fts_statp field) for each  file  visited.
248              This  option relaxes that requirement as a performance optimiza‐
249              tion, allowing the fts functions to set the  fts_info  field  to
250              FTS_NSOK  and  leave  the  contents of the fts_statp field unde‐
251              fined.
252
253       FTS_SEEDOT
254              By default, unless they  are  specified  as  path  arguments  to
255              fts_open(),  any  files  named  "."  or ".."  encountered in the
256              file hierarchy are ignored.  This option causes the fts routines
257              to return FTSENT structures for them.
258
259       FTS_XDEV
260              This  option  prevents fts from descending into directories that
261              have a different device number than the file from which the  de‐
262              scent began.
263
264       The  argument  compar()  specifies a user-defined function which may be
265       used to order the traversal of the hierarchy.  It takes two pointers to
266       pointers to FTSENT structures as arguments and should return a negative
267       value, zero, or a positive value to indicate if the file referenced  by
268       its  first  argument comes before, in any order with respect to, or af‐
269       ter, the file referenced by  its  second  argument.   The  fts_accpath,
270       fts_path,  and fts_pathlen fields of the FTSENT structures may never be
271       used in this comparison.  If the fts_info field is  set  to  FTS_NS  or
272       FTS_NSOK, the fts_statp field may not either.  If the compar() argument
273       is NULL, the directory traversal  order  is  in  the  order  listed  in
274       path_argv  for the root paths, and in the order listed in the directory
275       for everything else.
276
277   fts_read()
278       The fts_read() function returns a pointer to an  FTSENT  structure  de‐
279       scribing  a  file in the hierarchy.  Directories (that are readable and
280       do not cause cycles) are visited at least twice, once in  preorder  and
281       once  in  postorder.  All other files are visited at least once.  (Hard
282       links between directories that do not cause cycles or symbolic links to
283       symbolic  links may cause files to be visited more than once, or direc‐
284       tories more than twice.)
285
286       If all the members of the hierarchy have been returned, fts_read()  re‐
287       turns NULL and sets errno to 0.  If an error unrelated to a file in the
288       hierarchy occurs, fts_read() returns NULL and sets  errno  to  indicate
289       the error.  If an error related to a returned file occurs, a pointer to
290       an FTSENT structure is returned, and errno may or may not have been set
291       (see fts_info).
292
293       The FTSENT structures returned by fts_read() may be overwritten after a
294       call to fts_close() on the same file hierarchy stream, or, after a call
295       to fts_read() on the same file hierarchy stream unless they represent a
296       file of type directory, in which case they will not be overwritten  un‐
297       til  after a call to fts_read() after the FTSENT structure has been re‐
298       turned by the function fts_read() in postorder.
299
300   fts_children()
301       The fts_children() function returns a pointer to  an  FTSENT  structure
302       describing  the  first  entry  in  a NULL-terminated linked list of the
303       files in the directory represented by the  FTSENT  structure  most  re‐
304       cently returned by fts_read().  The list is linked through the fts_link
305       field of the FTSENT structure, and is  ordered  by  the  user-specified
306       comparison function, if any.  Repeated calls to fts_children() will re-
307       create this linked list.
308
309       As a special case, if fts_read() has not yet been called for a  hierar‐
310       chy,  fts_children()  will return a pointer to the files in the logical
311       directory specified to fts_open(), that is, the arguments specified  to
312       fts_open().   Otherwise, if the FTSENT structure most recently returned
313       by fts_read() is not a directory being visited in preorder, or the  di‐
314       rectory  does  not  contain  any files, fts_children() returns NULL and
315       sets errno to zero.  If an error occurs,  fts_children()  returns  NULL
316       and sets errno to indicate the error.
317
318       The FTSENT structures returned by fts_children() may be overwritten af‐
319       ter a call to fts_children(), fts_close(), or fts_read()  on  the  same
320       file hierarchy stream.
321
322       The instr argument is either zero or the following value:
323
324       FTS_NAMEONLY
325              Only the names of the files are needed.  The contents of all the
326              fields in the returned linked list of structures  are  undefined
327              with the exception of the fts_name and fts_namelen fields.
328
329   fts_set()
330       The function fts_set() allows the user application to determine further
331       processing for the file f of the stream ftsp.  The  fts_set()  function
332       returns 0 on success, and -1 if an error occurs.
333
334       The  instr  argument  is  either 0 (meaning "do nothing") or one of the
335       following values:
336
337       FTS_AGAIN
338              Revisit the file; any file type may be revisited.  The next call
339              to fts_read() will return the referenced file.  The fts_stat and
340              fts_info fields of the structure will be reinitialized  at  that
341              time,  but  no other fields will have been changed.  This option
342              is meaningful only for the  most  recently  returned  file  from
343              fts_read().  Normal use is for postorder directory visits, where
344              it causes the directory to be revisited (in  both  preorder  and
345              postorder) as well as all of its descendants.
346
347       FTS_FOLLOW
348              The  referenced file must be a symbolic link.  If the referenced
349              file is the one most recently returned by fts_read(),  the  next
350              call  to  fts_read()  returns  the  file  with  the fts_info and
351              fts_statp fields reinitialized to reflect the target of the sym‐
352              bolic  link instead of the symbolic link itself.  If the file is
353              one of those  most  recently  returned  by  fts_children(),  the
354              fts_info and fts_statp fields of the structure, when returned by
355              fts_read(), will reflect the target of the symbolic link instead
356              of  the  symbolic link itself.  In either case, if the target of
357              the symbolic link does not exist, the  fields  of  the  returned
358              structure  will  be unchanged and the fts_info field will be set
359              to FTS_SLNONE.
360
361              If the target of the link is a directory, the  preorder  return,
362              followed  by the return of all of its descendants, followed by a
363              postorder return, is done.
364
365       FTS_SKIP
366              No descendants of this file are visited.  The file may be one of
367              those   most  recently  returned  by  either  fts_children()  or
368              fts_read().
369
370   fts_close()
371       The fts_close() function closes the file hierarchy stream  referred  to
372       by  ftsp and restores the current directory to the directory from which
373       fts_open() was called to open ftsp.  The fts_close() function returns 0
374       on success, and -1 if an error occurs.
375

ERRORS

377       The  function  fts_open()  may fail and set errno for any of the errors
378       specified for open(2) and malloc(3).
379
380       The function fts_close() may fail and set errno for any of  the  errors
381       specified for chdir(2) and close(2).
382
383       The  functions fts_read() and fts_children() may fail and set errno for
384       any of the errors specified for chdir(2), malloc(3), opendir(3),  read‐
385       dir(3), and [l]stat(2).
386
387       In addition, fts_children(), fts_open(), and fts_set() may fail and set
388       errno as follows:
389
390       EINVAL options or instr was invalid.
391

ATTRIBUTES

393       For an  explanation  of  the  terms  used  in  this  section,  see  at‐
394       tributes(7).
395
396       ┌──────────────────────────────────────────┬───────────────┬───────────┐
397Interface                                 Attribute     Value     
398       ├──────────────────────────────────────────┼───────────────┼───────────┤
399fts_open(), fts_set(), fts_close()        │ Thread safety │ MT-Safe   │
400       ├──────────────────────────────────────────┼───────────────┼───────────┤
401fts_read(), fts_children()                │ Thread safety │ MT-Unsafe │
402       └──────────────────────────────────────────┴───────────────┴───────────┘
403

STANDARDS

405       None.
406

HISTORY

408       glibc 2.  4.4BSD.
409

BUGS

411       Before  glibc  2.23, all of the APIs described in this man page are not
412       safe when compiling a program using the LFS APIs (e.g., when  compiling
413       with -D_FILE_OFFSET_BITS=64).
414

SEE ALSO

416       find(1), chdir(2), lstat(2), stat(2), ftw(3), qsort(3)
417
418
419
420Linux man-pages 6.04              2023-03-30                            fts(3)
Impressum