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

[Paul Eggert]

Miklos Szeredi <address@hidden> writes:

> The legacy app will break regardless of how many files there are on
> the filesystem, or even wheter it needs to use the inode number or
> not.  It will break because the stat() family of syscalls will return
> with an error.

I don't see why.  The kernel should be able to tell whether the app
has called the old (smallfile) stat function, or the new stat
function.  If the app calls the old stat function, the kernel can give
it a 32-bit inode number.  If the app calls the new stat function, the
kernel can give it a 64-bit inode number.  The two inode numbers do
not have to agree.

This is not a perfect solution (for example, a smallfile legacy app
can't print an inode number and give it to a modern app), but it's
good enough.  Failure modes will be quite rare and easily explained,
just as they're explained for the 2 GiB limitation on smallfile legacy
aps (a problem that's considerably more important).

> it is _NOT_POSSIBLE_ to make these filesystems conform to POSIX.

Sure it is.  All it takes is sufficient resources.  You could maintain
an auxiliary inode table outside the file system, for example.  But
I'm trying to help generate a solution that's more efficient than
that, one that is "good enough" to support the obsolescent software
you're worried about.