[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers
Date: Sat, 30 Sep 2006 07:35:55 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060909 Thunderbird/ Mnenhy/

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

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

Eric Blake             address@hidden
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


reply via email to

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