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

[Miklos Szeredi]

> >> If it's for legacy apps, tell people to recompile with largefile
> >> support.
> >
> > Paul, please!  It is ridiculous to require end users to recompile
> > their applications or kernels or anything.
> 
> A small-file legacy app, one that cannot handle files larger than 2
> GiB, is already quite a limited app these days.  Such a program will
> do just fine with 32-bit inode numbers in practice, as people won't
> expect much of it.  If someone complains that such an app doesn't work
> with a lot of files (e.g., the 470,000 files on your root file
> system), then you tell them "sorry, you've got a legacy app built for
> a small environment; please recompile it".  It's exactly what you'd
> tell them when their program doesn't work with a 2.5 GiB file.

You haven't been reading carefully enough.

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.

Believe me, you don't want this.

> >> There is a standard for this, a standard that reflects longstanding
> >> practice.
> >
> > Which is what I have been doing.
> 
> Then I'm afraid I'm totally lost.  If POSIX says that inodes must be
> unique and stable, and if the file system is conforming to POSIX, then
> what's the problem?

The problem (as I have stated _many_ times) is that it is
_NOT_POSSIBLE_ to make these filesystems conform to POSIX.  I'm
eagerly waiting for an idea that proves me wrong.

Your suggestion for using 64bit hashes came close, but it turns out to
be unworkable on the majority of systems.

Miklos