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

[James Youngman]

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
realising).  

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:

  <http://savannah.gnu.org/bugs/?23443>

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