[Top][All Lists]

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

[bug #23443] find regression: now fooled when crossing mountpoints

From: James Youngman
Subject: [bug #23443] find regression: now fooled when crossing mountpoints
Date: Mon, 02 Jun 2008 10:27:24 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20080404 Iceweasel/ (Debian-

Update of bug #23443 (project findutils):

                Category:                    None => find                   
              Item Group:                    None => Wrong result           
             Assigned to:                    None => jay                    


Follow-up Comment #5:

Editing the full output you gave:-

# stat /suse/jw/.snapshot/hourly.0 /suse/jw/.snapshot
  File: `/suse/jw/.snapshot/hourly.0'
  Size: 28672           Blocks: 56         IO Block: 8192   directory
Device: 1bh/27d Inode: 67          Links: 75

  File: `/suse/jw/.snapshot'
  Size: 4096            Blocks: 8          IO Block: 8192   directory
Device: 1bh/27d Inode: 67          Links: 5

POSIX requires find implementation to detect filesystem loops (e.g. cases
where are hard link to a parent or grandparent directory exists).   That's a
POSIX requirement.  I guess the thinking behind that is to avoid
non-terminating searches.  Anyway, as far as I understand it, POSIX also
requires that a single device/inode pair should uniquely identify a file.   
GNU findutils uses a list of 'ancestor' dev/inode numbers to figure out if
it's seen this directory before in order to detect such loops.  That should be
sufficient to prevent false negatives (i.e. being inside a loop without

However, in this case we have a false positive (there is no loop but find
thinks there is).  I can't right now think of any change that will remove this
false positive without exposing us to the risk of a false negative.   If we
can find a way of fixing this problem without risking non-POSIX-compliance,
I'm happy to do it.   But no approach seems obvious to me right now.  

NetApp filers have a directory layout similar to the one you seem to have,
but I think they generally avoid this problem by ensuring that ".snapshot" is
not returned by readdir(3) even though it is possible to stat that directory,
chdir into it, and so forth.   That generally seems like a workable solution. 
 However, it looks like readdir is returning ".snapshot" in your case.  Maybe
you're not on a NetApp filer, just something that looks a bit similar.  

Anyway, to summarise, the wrong thing does seem to be happening here, but I
can't think of a way to work around the problem without sacrificing POSIX
compliance.   Any suggestions?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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