[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Youngman
Subject: [bug #19605] find does not report symlink loop when trying to follow symlinks
Date: Tue, 17 Apr 2007 10:27:12 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060830 Firefox/ (Debian-1.5.dfsg+

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 for the reason you originally stated.  

I would regard the "find -L a/foo" problem (which also affects -P and -H) to
be a separate (and catastrophic) bug.   I've logged a sepaarte bug for it.

When -L is in effect, if an attempt to stat("x") fails with ELOOP for some
directory entry x,  find will not try to recurse into x.  

If find does not descend into "x", is it required to issue a diagnostic under
the infinite loop rule?  My reading of
http://www.opengroup.org/onlinepubs/009695399/utilities/find.html is that the
diagnostic is only required for directories find actually enters (or tries to
enter) and which are ancestors.

In this example I can see two reasons why a diagnostic would not be
1. x (or in our earlier example a and b) does not point to an ancestor of any
directory actually visited.
2. x is not entered.

I think either of reasons (1) and (2) should be sufficient to avoid a
diagnostic required by the statement:

<< The find utility shall detect infinite loops; that is, entering a
previously visited directory that is an ancestor of the last file
encountered. >>

You write:

With the -L option find follows symlinks, so all the pathnames it writes to
stdout should be files that exist when symlinks are followed. If "a" is a
symlink loop it effectively does not exist when symlinks are followed,
because the pathname does not resolve successfully. 

This, I believe, is a very good reason to omit printing names corresponding
to symlink loops.   I'm not completely convinced that a diagnostic should be
issued in this case.  However, I can understand that the user might want to
be able to control this.  Control over this sort of thing is essentially
already provided though, via -L, -P and -H.  

If the user does not care about symbolic link destinations, they will be in
-P mode.    Hence I would interpret use of -L as indicating that the user
cares about where symbolic links point, and so I believe that find should be
modified to issue a diagnostic in this case.  

I believe at this stage that "find -H a" should behave similarly to "find -P
a" when a is a symlink loop, since the "referenced file does not exist" (that
is, no file is referenced).   Therefore for that case, no diagnostic.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]