[bug #19619] findutils-4.3.3 does not build on Cygwin

Update of bug #19619 (project findutils): Status:None => Need Info Assigned to:None => ericb ___ Follow-up Comment #1: I have applied t

[bug #19617] Nonexistent start points are not diagnosed in findutils-4.3.3

Update of bug #19617 (project findutils): Status:None => Fixed ___ Follow-up Comment #1: This was fixed by the same code change as Savannag bug #19605. _

[bug #19605] find does not report symlink loop when trying to follow symlinks

Update of bug #19605 (project findutils): Status:None => Fixed ___ Reply to this item at: ___

[bug #19619] findutils-4.3.3 does not build on Cygwin

URL: Summary: findutils-4.3.3 does not build on Cygwin Project: findutils Submitted by: jay Submitted on: Tuesday 04/17/2007 at 14:02 Category: None Severity: 3 - Norm

Re: Problems in findutils-4.3.3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to James Youngman on 4/17/2007 4:01 AM: > > If there are other bugs you would consider critical for 4.3.4, please > mention them to me now. 4.3.3 will not build out-of-the-box on cygwin, because it relies on gnulib's tests, which had a bug

[bug #19605] find does not report symlink loop when trying to follow symlinks

Follow-up Comment #8, bug #19605 (project findutils): You are still trying to bring the POSIX requirements for directory loop detection into this, which I have already pointed out are a completely different thing and not relevant. The requirements for a diagnostic in the symlink loop case come f

[bug #19605] find does not report symlink loop when trying to follow symlinks

Update of bug #19605 (project findutils): Assigned to:None => jay ___ Follow-up Comment #7: Executive summary: I agree that a diagnostic should be issued when -L is in effect, but not f

[bug #19617] Nonexistent start points are not diagnosed in findutils-4.3.3

Update of bug #19617 (project findutils): Category:None => find Item Group:None => Wrong result Release:None => 4.3.3 __

[bug #19617] Nonexistent start points are not diagnosed in findutils-4.3.3

URL: Summary: Nonexistent start points are not diagnosed in findutils-4.3.3 Project: findutils Submitted by: jay Submitted on: Tuesday 04/17/2007 at 10:05 Category: None

Problems in findutils-4.3.3

As you will be able to see from http://savannah.gnu.org/bugs/?group=findutils, a number of bugs have been discovered in findutils-4.3.3. Some of these are quite serious. I would advise you not to install findutils-4.3.3 in environments other than test environments. A release of findutils-4.3.4

[bug #19605] find does not report symlink loop when trying to follow symlinks

Follow-up Comment #6, bug #19605 (project findutils): On second thoughts, d_type is a red herring. With the -L option, d_type doesn't provide enough information for symlinks - find needs to know what type of file the symlink points to (in order to tell whether the symlink points to a directory t

[bug #19605] find does not report symlink loop when trying to follow symlinks

Follow-up Comment #5, bug #19605 (project findutils): I take your point about d_type (the system I tried it on does have d_type). I still think that find should report this error. With the -L option find follows symlinks, so all the pathnames it writes to stdout should be files that exist when

[bug #19616] leaf optimisation and loop detection broken in 4.3.3

Update of bug #19616 (project findutils): Status:None => Fixed ___ Reply to this item at: ___

[bug #19616] leaf optimisation and loop detection broken in 4.3.3

URL: Summary: leaf optimisation and loop detection broken in 4.3.3 Project: findutils Submitted by: jay Submitted on: Tuesday 04/17/2007 at 09:00 Category: find Severi

[bug #19605] find does not report symlink loop when trying to follow symlinks

Follow-up Comment #4, bug #19605 (project findutils): But find does nto need to stat() a directory entry in order to discover that the entry itself is not a directory. Using -size causes the loop tobe diagnosed, because that requries a call to stat(). Determining that an item is not a directory

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

Update of bug #19613 (project findutils): Status:None => Fixed ___ Reply to this item at: ___

[bug #19615] findutils 4.3.3 incorrectly claims to be using FTS_CWDFD

Update of bug #19615 (project findutils): Status:None => Fixed ___ Reply to this item at: ___

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

Follow-up Comment #1, bug #19613 (project findutils): This bug affectes only findutils-4.3.3 (that is, not previous versions). ___ Reply to this item at: ___

[bug #19605] find does not report symlink loop when trying to follow symlinks

Follow-up Comment #3, bug #19605 (project findutils): You are confusing directory loops and symlink loops, which are completely different things. In a directory loop, a symlink points up to a parent directory of the symlink. A stat() of the symlink succeeds. In a symlink loop the symlink ends

[bug #19615] findutils 4.3.3 incorrectly claims to be using FTS_CWDFD

URL: Summary: findutils 4.3.3 incorrectly claims to be using FTS_CWDFD Project: findutils Submitted by: jay Submitted on: Tuesday 04/17/2007 at 08:37 Category: find Se

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

URL: Summary: findutils 4.3.3 assertion failure on symbolic link loop on NetBSD Project: findutils Submitted by: jay Submitted on: Tuesday 04/17/2007 at 07:55 Category: find

[bug #19605] find does not report symlink loop when trying to follow symlinks

Follow-up Comment #2, bug #19605 (project findutils): Thinking about this again, I am less convinced this is a bug. AIUI find is required to diagnose directory loops. The standard says: << The find utility shall detect infinite loops; that is, entering a previously visited directory that is an