cvs commit: src/include fts.h src/lib/libc/gen fts.3

[David Schultz]

On Wed, Jan 12, 2005, Tim Kientzle wrote:
> Pawel Jakub Dawidek wrote:
> >pjd         2005-01-12 07:35:09 UTC
> >
> >  FreeBSD src repository
> >
> >  Modified files:        (Branch: RELENG_5)
> >    include              fts.h 
> >    lib/libc/gen         fts.3 
> >  Log:
> >  MFC:    fts.h   1.11
> >          fts.3   1.22
> >  
> >  Introduce new field 'fts_bignum' which is 64bit long and will allow to
> >  make utilities like du(1) 64bit-clean.
> >  When this field is used, one cannot use 'fts_number' and 'fts_pointer'
> >  fields.
> >  
> >  This commit doesn't break API nor ABI.
> >  
> >  This work is part of the BigDisk project:
> >  
> >          http://www.FreeBSD.org/projects/bigdisk/
> 
> Any plans to deal with other fts limits,
> such as the inability to perform a logical
> traversal of a path longer than PATH_MAX or
> to reduce memory consumption when dealing
> with very large directory trees?

Removing FTS_LOGICAL's path length limitation is nontrivial, but
given your experience with bsdtar, I'd say you're an ideal person
to do it.  ;-)

AFAIK, the problem is that fts() effectively uses chdir("..") to
climb up one level in the tree in chdir mode.  If it chdir'd
across a symlink earlier, this would put it in the wrong place.
Perhaps you have a better solution, but my best idea is to keep
the parent directory open when chdiring across a symlink, making
it possible to fchdir() back to the parent.  Additional
complications are needed to decide, at each step, whether to
ascend using the stack of parent references or using chdir("..").

A more uniform approach would be to keep all the "ancestor"
directories open during the traversal, i.e., always keep the
parent open when descending a level.  Unfortunately, this limits
the traversal depth to the number of available file descriptors.
(On the other hand, I would argue that anyone with a directory
tree a few thousand levels deep is asking for trouble.)