Date: Wed, 12 Jan 2005 19:39:18 -0800 From: Tim Kientzle <kientzle@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/include fts.h src/lib/libc/gen fts.3 Message-ID: <41E5ED66.4070902@freebsd.org> In-Reply-To: <200501120735.j0C7ZABq048856@repoman.freebsd.org> References: <200501120735.j0C7ZABq048856@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? I've been tinkering with an alternative to fts for use in bsdtar that doesn't have such limits, but would also be interested in fixing fts, also. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41E5ED66.4070902>