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

[Jim Meyering]

Miklos Szeredi <address@hidden> wrote:
>> > Shouldn't holding the current directory open prevent the ancestor from
>> > changing inodes in this case?
>>
>> No.
>> What's changed is the identity (dev/inode) of the parent directory,
>> once you try to chdir("..") "up" beyond the renamed directory.
>
> I understand, that that is the case you want to detect.
>
> But in the normal case (no changes in topology) the parent was
> referenced thoughout traversing it's subtree, hence it's inode number
> cannot have changed even for an inode-less filesystems.
>
> So I think the problem we are seeing is not for traversing up the
> tree, but for traversing down it.

Correct.

> In which case the check is not
> needed (if O_NOFOLLOW is also available).

Unfortunately, we can't yet afford to target only systems with
open/O_NOFOLLOW support, and we do care about security on other systems.

The real problem is that these inode-less file systems violate
long-standing practice.  And *many* applications depend on being able to
lstat a file and (soon afterward) open the same file, and then require
that the before and after inodes match.

Have you considered changing FUSE so its caching mechanism is less likely
to flush data for active directory inodes?