Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Replying outside of savannah, and adding bug-gnulib, since ultimately,
the behavior in question is a result of gnulib's fts]

According to Geoff Clare on 9/30/2006 5:53 AM:
> Follow-up Comment #6, bug #17877 (project findutils):
> 
> Good point about inode numbers being reused.
> 
> This means that what you can tell from comparing inode numbers (obtained from
> pathnames), according to POSIX, is:
> 
> * If the inode numbers are different, the file is definitely a different
> file.
> 
> * If the inode numbers are the same, the file might be the same file or it
> might be a different file that has been assigned the same inode number.
> 
> The ambiguity in the second case can be avoided by obtaining the first inode
> number from an open fd (which is then kept open) instead of a pathname.  (Or
> an fd could be used to obtain the second inode number, as long as it was open
> at the time the first inode number was obtained.)
> 
> (All of the above assumes that the device numbers are the same.)
> 
>     _______________________________________________________
> 
> Reply to this item at:
> 
>   <http://savannah.gnu.org/bugs/?17877>

For the gnulib crowd, a summary of the above link is that find 4.3.0,
which uses gnulib's fts, is sometimes reporting "No such file or
directory" in the middle of traversal on non-POSIX file systems such as
smbfs, cifs, sshfs, or fat, where the combination of the file system
representation on disk and/or the remote server and caching issues makes
it possible for a file's inode to change over time; or even for inodes to
be reused in a short period of time on different files.

Indeed, if the SAME file has two different inodes over time, that file
system violates POSIX, but such systems do exist, and wreak havoc in
fts()'s algorithm to traverse directories, because fts is not maintaining
an open fd to each directory that it is in, but closes and then reopens
the directories as it goes.  Yet, keeping fds open is expensive - on a
pathologically deep hierarchy, there are systems that do not have enough
fds available to traverse the entire hierachy with an open fd for every
intermediate path, so you have to close and reopen directories as the
algorithm progresses if you are to visit everything.

On the opposite side of things, I don't know if fts() is or can be made
robust to two distinct files being given the same inode due to an unlink
and new file creation occuring during traversal, although I seem to recall
an attempt in the past to make rm (which uses fts) more robust along these
lines.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFHnK684KuGfSFAYARAo0FAJ98yta6UE0vAgG9SnCeipt8kp2lSgCgv/iR
MNdPL+avqp9zVhW/7yJEua0=
=DnHu
-----END PGP SIGNATURE-----