Date: Fri, 7 May 2004 15:23:46 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Tim Kientzle <tim@kientzle.com> Cc: Andrew.Li@alcatel.com.au Subject: Re: cvs commit: src/usr.bin/tar fts.c fts.h Message-ID: <20040507052346.GA80829@gsmx07.alcatel.com.au> In-Reply-To: <40986014.4010507@kientzle.com> References: <200405041721.i44HL22l029797@repoman.freebsd.org> <20040504232632.GA69416@gsmx07.alcatel.com.au> <40986014.4010507@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2004-May-04 20:31:32 -0700, Tim Kientzle <tim@kientzle.com> wrote:
>Peter Jeremy wrote:
>>Since a colleague of mine has just finished porting fts(3) to Tru64,
>
>Patches?
...
>So far, I've heard reports from people using bsdtar/libarchive on
>FreeBSD 5, FreeBSD 4, and Linux. If someone sends me patches for
>another system, I'm happy to integrate them. <hint, hint> ;-)
Actually, we were porting du(1) rather than bsdtar/libarchive. The du
built into Tru64 is seriously broken[1] and the FreeBSD one seemed an
easy solution. The fts(3) changes are functionally equivalent to
yours but implemented without the #ifdef's so the code is not portable.
[1] If the content of a directory changes whilst it is processing the
directory, it will give nonsense results - similar to:
$ du -sk .
du: File not found ./foo
0 ./foo
$
>>Also, why wasn't this done as a repocopy? This would have made it far
>>easier to see the changes.
>
>Duh! My inexperienced commiter-ness is showing through again,
>isn't it? <sigh>
Raise the issue with cvs@, it might still be possible (it would mean
that two different v1.1's would have existed, but the dates are
sufficiently separated that it may be allowed).
--
Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040507052346.GA80829>