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

[Jim Meyering]

Miklos Szeredi <address@hidden> wrote:
>> Thanks for forwarding that.
>> I confess I hadn't looked at the original bug report.
>> Just did, and see that it's a different problem than I first thought.
>> I now see that this is about the dev/ino check when traversing "up"
>> to return to a previously visited directory.
>>
>> I find it hard to believe that a commonly used file system implementation
>> fails to preserve the dev/ino of a component of some process's working
>> directory.  IMHO, even when it's been unlinked, such a directory cannot
>> be considered "unreferenced" when a process is still using it.
>
> Ahh, but fts doesn't seem to have cwd or ancestor of cwd in the "lost"
> directory.

For the record, by "working directory", I mean to include what
gnulib's fts uses as a virtual working directory, represented by
a file descriptor open on the "current" directory being processed.
But from your strace output below, I see that even that doesn't apply.

> Look at this strace snipplet from 'find /mnt/fuse/tmp/test':
>
> lstat64("/mnt/fuse/tmp/test", {st_dev=makedev(0, 14), st_ino=3}...) = 0
...
> open   ("/mnt/fuse/tmp/test", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
> fstat64(5, {st_dev=makedev(0, 14), st_ino=5}) = 0

> No file decriptor or cwd refers to /mnt/fuse/tmp/test between the
> lsta64 and the later ftstat64 on the open file.

I presume you mean "between the initial lstat64 and the open".

Are you saying that with your FUSE patch, the above is to be expected?
Meaning, the inode numbers are expected to differ, even if nothing
happens to "/mnt/fuse/tmp/test" during the "..." period?

IMHO, any file system implementation that "works" that way is
seriously flawed, since hierarchy-traversing tools like find, chmod
-R, rm -r, etc. must detect attempts to subvert them with symptoms
that are nearly identical.  Those same tools are often required to
stat or lstat a file or directory before performing an operation
on it.  Of course, ideally, one would open the file system object,
and *then* determine its type from the descriptor and operate on
the descriptor, but that's not always possible.

The point is that it is important for any file system to provide
the same device and inode numbers upon repeated accesses to the
same logical file system object, unless that object has been e.g.,
removed or moved aside and then replaced.

If your patch makes a FUSE-based file system violate such a
fundamental assumption, then I think problems are inevitable.