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

[Paul Eggert]

Miklos Szeredi <address@hidden> writes:

> 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.  Why can't the file system tell what system call
was used (the legacy smallfile one or the largefile one)?  Surely
there is some way to find out, even if it's not as convenient as we'd
like.  And if there's no such way, then add one.

If it's too much trouble to implement this, then just issue 32-bit
hashes.  That's not perfect, but it'll be good enough for most casual
uses.  Or have it be a mount-time option whether to use 32-bit hashes
(to support smallfile legacy apps, albeit with some collisions
possible) or 64-bit hashes (to support modern apps, with little
possibility of collision).

There are lots of ways to go here, without having to port standard
utilities to substandard file systems (which has the side effect of
dumbing the utilities down and making them less secure).

> If you were thinking of automatically converting a 64bit inode number
> to a 32bit one (e.g. truncating it)

Yes, I was thinking of the _filesystem_ doing that.  Not glibc.  Not
the kernel.  The _filesystem_.  It's the filesystem's responsibility
to know that its inode numbers are somewhat bogus; the kernel and/or
glibc can't be expected to know that on their own.

> 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.  There must already be such problems with hard links
anyway, so this extra problem isn't that much worse.

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

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

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.  People will just have to learn to not trust running standard
utilities on file systems that lack reliable-enough inode numbers.