James Youngman wrote:
> [ adding nug-gnulib to CC since we're discussinf its fts implementation ]
>
> On Sun, Mar 8, 2009 at 2:50 PM, George Spelvin wrote:
>> James Youngman wrote:
>>> The updated patches are what I actually pushed (into 4.5.x).
>>
&g
James Youngman wrote:
> The updated patches are what I actually pushed (into 4.5.x).
Ah, thank you. The posted patches wouldn't apply to savannah git HEAD
due to a conflict in the ChangeLog. (Easy enough to work around, but
worrisome.)
The (tested) simplified version is, of course,
+ boolean
(Resend because I can't spell "bug-findutils".)
Thanks for the fix! Sorry it fell off the bottom of my to-do pile.
If I might suggest, the code here does not express the logic very clearly:
diff --git a/find/util.c b/find/util.c
index 2570682..bbc8436 100644
--- a/find/util.c
+++ b/find/util.c
"James Youngman" <[EMAIL PROTECTED]> wrote:
> This is something that find has needed for quite a while. There is a
> somewhat more general problem too - the ftsfind program itself seems
> to stat files that fts() already stated, I think.
>
> There may also be other opportunities for improvement,
"James Youngman" <[EMAIL PROTECTED]> wrote:
> Based on what you write I would assume that this is true for both the
> find and the oldfind executables built in all even vaguely-recent
> findutils releases.
Er... I'm not familiar with the oldfind executable. I'm using the
Debian-compiled amd64 4.4
Looking for an inode that fsck complained about, I did a find,
and noticed that it was statting every file name it found.
Hunting through the code, I see that, in tree.c, pred_inum is marked
NeedsStatInfo. Is there a reason that struct dirent's d_ino field
can't be used instead? That would drast
