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

[Miklos Szeredi]

> > If you were thinking of a soltuion, where the filesystem itself
> > supplies two different inode numbers based on the variant of the
> > userspace interface, then I'm sorry to inform you, that this sort of
> > interface is not likely to happen in the Linux kernel.
> 
> I don't see why not.

Because it would be a horrible hack, and generally those are frowned
upon by Linux developers.  If you don't beleive me, just talk to Al
Viro about it.

> (which has the side effect of dumbing the utilities down and making
> them less secure).

This is just FUD.  From what I understand, the solution for the find
problem will actually make fts more optimal in some cases even for
POSIX filesystems, and will cause no regressions whatsoever.

> > However, I realized that inode numbers generated by hashing the path
> > have another fatal problem.  Namly that if you rename a file or
> > directory, then the inode number will of course move with the name,
> 
> I was relying on your earlier statement that a file was uniquely
> identified by its path, and that therefore a rename results in a
> different file.  Those semantics are not great, but they're better
> than nothing.

And are blatantly POSIX violating.

> There must already be such problems with hard links anyway, so this
> extra problem isn't that much worse.

Yes it is.  Neither sftp, nor smbfs, nor fat support hard links.  All
of them support rename.

> >> Sure it is.  All it takes is sufficient resources.  You could maintain
> >> an auxiliary inode table outside the file system, for example.
> >
> > And this could be an ever growing table, as the filesystem may not be
> > aware of any removals on the server end.
> 
> That's not a problem.  If the table has garbage and gets too large
> then the file system can garbage-collect it.

Based on what?  The filesystem has _no_ information about which inodes
may be still valid, and which may not.

> I don't seriously expect you to rush out and implement the inode table
> right away.  All I'm trying to show is that it's indeed possible to
> implement POSIX semantics, so that the claim that "it is
> _NOT_POSSIBLE_ to make these filesystems conform to POSIX" is
> incorrect.  With an auxiliary table, one can even implement
> POSIX-style renames and hard-links.  The issue is not whether it is
> _possible_ to conform to POSIX; it clearly is.

What about embedded devices, where the table would not fit in memory?
My guess is that an entry in such a table would be minimum 32bytes.  A
million such entries would take 32Mbytes.

Yes with infinite resources the problem is clearly solvable.  But
that's not what I'm interested in.

> The issue is to find a reasonable design point where the most
> commonly-run applications work and where it doesn't cost too much to
> implement it.

Yup.

> Again, it is unreasonable to expect standard utilities to port around
> file systems that don't have reliable inode numbers.  It breaks too
> many other things: simplicity and security being the most important
> two.

It breaks neither of those.  You are clearly just making this up,
without understanding the issues.  If you are actually interested in
what's involved in fixing an application please follow the discussion
on gnulib-bugs.

> People will just have to learn to not trust running standard
> utilities on file systems that lack reliable-enough inode numbers.

We'll see.

Miklos