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

[Miklos Szeredi]

> > 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".

Yes.

> 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?

No, what I'm saying that some filesystem cannot _guarantee_ that the
inode number will not change between two operations, unless an open
file descriptor or a cwd is refering to the inode.

The filesystem can make an effort to keep inodes cached as long as
memory constraints allow.  And until the inode is cached it's number
doesn't change.  When it's evicted from the cache and the filesystem
has no way of reconstructing that number, than it's _impossible_ to
allocate the same inode number to the same file.

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

My test filesystem makes it easy to reproduce problems which are
otherwise much harder to reproduce.  It doesn't change anything about
the assumptions the application can make about these "inodeless"
filesystems.

Miklos