-----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 [EMAIL PROTECTED] -----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-----
