[bugs #11148] find does not report symlink loop when trying to follow symlinks

[James Youngman]

This mail is an automated notification from the bugs tracker
 of the project: findutils.




/**************************************************************************/
[bugs #11148] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11148>
Project: findutils
Submitted by: Geoff Clare
On: Sat 11/27/04 at 11:41

Category:  find
Severity:  5 - Average
Item Group:  None
Resolution:  None
Privacy:  Public
Assigned to:  jay
Originator Name:  
Originator Email:  
Status:  Open
Release:  4.2.8
Fixed Release:  None


Summary:  find does not report symlink loop when trying to follow symlinks

Original Submission:  In the following situation, find should report an error:

ln -s a b
ln -s b a
find -L a -print

Likewise for -H.  Instead, find is doing an lstat() when the stat() fails (with 
ELOOP).

The optionl_stat() and optionh_stat() functions need to distinguish been 
different stat() errors, and only do the lstat() when appropriate. They should 
do the lstat() if stat() failed with ENOENT.  It may be appropriate for some 
other errors as well (e.g. ENOTDIR), but definitely not for ELOOP.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Sat 11/27/04 at 19:24         By: James Youngman <jay>
Summary - I have fixed bugs, but not the one you reported.  Please read on to 
discover what I did and why.

I disagree with your interpretation.  My reading of the POSIX standard tis that 
the find utility is only required to diagnose an infinite loop if it enters a 
directory forming part of that loop.  Hence I don't think the specific example 
you gave is entirely appropriate.   The diagnostic message is presumably 
intended to warn the user that the output of find may not be as they expect.   

However, there are (were) indeed closely related problems with findutils-4.2.8. 
 There are three interesting cases:

1. Infinite cycles involving hard links to directories.    These were 
previously detected and find used to silently avoid visiting any particular 
directory entry which was a hard link to one of its ancestors (where the 
ancestor had not already been visited, the loop would be detected later).
The effect of the leaf optimisation is frequently such that find knows that it 
doesn't need to examine such entries anyway (the deep directory entry does not 
contribute to the link count of its immediate parent).   I have implemented a 
bugfix in the CVS code, which is to issue a diagnostic when this happens, 
instead of silently avoiding such cycles.

2. Loops including symbolic links.  There were problems diagnosing this since 
the -L option had failed to imply -noleaf, contrary to what the documentation 
said.   Your bug report led me to check this, and so I have just fixed this in 
CVS.

3. Symbolic links which cause ELOOP (i.e. your example).  I think that in this 
case findutils-4.2.8 treats these as if they were broken symbolic links.  I 
think that's a reasonable interpretation.  The (admittedly non-normative) 
RATIONALE text states:

"Since the -L option resolves all symbolic links and the -type l primary is 
true for symbolic links that still exist after symbolic links have been 
resolved, the command:

find -L . -type l

prints a list of symbolic links reachable from the current directory that do 
not resolve to accessible files."

Since symlinks pointing to each other do not resolve to accessible files (or 
directories) I think it is reasonable for "find -L . -type l" to print them.  
Does your interpretation match this?  If not, can you explain why you expect 
something else?   

I attach a compressed tar file which contains a "symbolic link torture test" 
for "find -L".  I also insert below the result of running the development code 
on it.  The second attachment is a hand-crafted ext2 filesystem image which has 
an infinite loop in it.  Please take care when testing with the filesystem 
image, it may not be kind to your system!

--- symbolic link torture test result ---
$ set -x ; ls -lR   /tmp/testdir/symloop ; ./find -L  /tmp/testdir/symloop -ls
+ ls -lR /tmp/testdir/symloop
/tmp/testdir/symloop:
total 1
lrwxrwxrwx  1 james users    2 2004-11-27 18:40 a -> ..
lrwxrwxrwx  1 james users   17 2004-11-27 18:42 b -> subdir/mid/bottom
lrwxrwxrwx  1 james users    3 2004-11-27 19:04 boo -> far
lrwxrwxrwx  1 james users    3 2004-11-27 19:04 far -> boo
drwxr-xr-x  3 james users 1024 2004-11-27 18:50 subdir

/tmp/testdir/symloop/subdir:
total 1
drwxr-xr-x  3 james users 1024 2004-11-27 18:50 mid

/tmp/testdir/symloop/subdir/mid:
total 1
drwxr-xr-x  2 james users 1024 2004-11-27 18:49 bottom

/tmp/testdir/symloop/subdir/mid/bottom:
total 1
-rw-r--r--  1 james users 6 2004-11-27 18:49 deepfile
+ ./find -L /tmp/testdir/symloop -ls
 16636    1 drwxr-xr-x   3 james    users        1024 Nov 27 19:04 
/tmp/testdir/symloop
 16635    1 drwxr-xr-x   3 james    users        1024 Nov 27 19:06 
/tmp/testdir/symloop/a
./find: Filesystem loop detected; `/tmp/testdir/symloop/a/symloop' has the same 
device number and inode as a directory which is 2 levels higher in the 
filesystem hierarchy.
 16636    1 drwxr-xr-x   3 james    users        1024 Nov 27 19:04 
/tmp/testdir/symloop/a/symloop
 16646    1 -rw-r--r--   1 james    users         311 Nov 27 19:06 
/tmp/testdir/symloop/a/symloop.tar.gz
 16638    1 drwxr-xr-x   2 james    users        1024 Nov 27 18:49 
/tmp/testdir/symloop/b
 16642    1 -rw-r--r--   1 james    users           6 Nov 27 18:49 
/tmp/testdir/symloop/b/deepfile
 16639    1 drwxr-xr-x   3 james    users        1024 Nov 27 18:50 
/tmp/testdir/symloop/subdir
 16640    1 drwxr-xr-x   3 james    users        1024 Nov 27 18:50 
/tmp/testdir/symloop/subdir/mid
 16638    1 drwxr-xr-x   2 james    users        1024 Nov 27 18:49 
/tmp/testdir/symloop/subdir/mid/bottom
 16642    1 -rw-r--r--   1 james    users           6 Nov 27 18:49 
/tmp/testdir/symloop/subdir/mid/bottom/deepfile
 16643    0 lrwxrwxrwx   1 james    users           3 Nov 27 19:04 
/tmp/testdir/symloop/far -> boo
 16644    0 lrwxrwxrwx   1 james    users           3 Nov 27 19:04 
/tmp/testdir/symloop/boo -> far








File Attachments
-------------------

-------------------------------------------------------
Date: Sat 11/27/04 at 19:34  Name: ext2-fs-withloop.bin.gz  Size: 10.81KB   By: 
jay
CAUTION: ext2 filesystem with loop
http://savannah.gnu.org/bugs/download.php?item_id=11148&amp;item_file_id=1923

-------------------------------------------------------
Date: Sat 11/27/04 at 19:24  Name: symloop.tar.gz  Size: 311B   By: jay
Symbolic loop torture test
http://savannah.gnu.org/bugs/download.php?item_id=11148&amp;item_file_id=1922






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=11148>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/