Follow-up Comment #7, bugs #12044 (project findutils):
>I can imagine situation where one can subvert subdirectory >with symlink to
another subdirectory in the same directory.
>Second check cannot catch this situation.
Very good! You've found a hole in the stat("..") strategy.
I (Martin B
Follow-up Comment #6, bugs #12044 (project findutils):
Regarding the fragility of OS version checks:
It is well accepted now that OS version checks
are a maintenance nightmare. The "configure revolution"
of relying as much as possible on feature tests, either
at compile time or run time ha
That was what it needed
Thanx
-Original Message-
From: '[EMAIL PROTECTED]' [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 22, 2005 2:11 PM
To: Giordano, John
Cc: bug-findutils@gnu.org; '[EMAIL PROTECTED]'
Subject: Re: your mail
On Tue, Feb 22, 2005 at 01:40:14PM -0500, Giordano, Jo
Follow-up Comment #5, bugs #12044 (project findutils):
I like first (chdir/fchdir-back/retry) approach more than second
(stat./chdir/stat..).
I can imagine situation where one can subvert subdirectory with symlink to
another subdirectory in the same directory.
Second check cannot catch this situ
Tested on a Solaris 8 machine, fully patched. gcc 3.4.3, gmake 3.80.
gmake distclean
executed in the findutils 4.2.18 (and possibly earlier 4.2.x) source root
causes regex.c in gnulib/lib to be deleted.
To reproduce:
./configure in source root
(optional) gmake
(optional) gmake install
gmake
Follow-up Comment #4, bugs #12044 (project findutils):
I tlike the idea of doing stat("..") after the chdir. I'l have a think about
that to see if it has any hidden gotchas.
The O_FOLLOW check simply copes with the case where find was compiled on a
new system and is being run on a very old
On Wed, Feb 23, 2005 at 03:58:21AM +0100, Mave wrote:
> Hello,
>
> i have a problem (it seems to be a bug) by using GNU find
> version 4.1.7 on a Debian 3 Woody with Pinning (Unstable/Testing)
Please note that the current stable release of findutils is 4.2.18.
> I want to find files named *.cfg
Follow-up Comment #3, bugs #12064 (project findutils):
This is very odd. I don't get the same effect in gnulib/m4/Makefile.in.
I've tested this with automake-1.7, automake-1.8 and automake-1.9 (all with
autoconf-2.59). In each case the Makefile.in file is correct and ends like
this:
.PHONY:
Follow-up Comment #3, bugs #12044 (project findutils):
The current situation of having find hang when any remote
NFS server is unreachable is unacceptable, since it makes
my carefully engineered scripts fail due to the whims of
a flaky network. I carefully prune PATH, for example,
to have as
