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

[Miklos Szeredi]

> >> If files are identified by the path, then you can hash the
> >> path. If you use a good 64-bit hash the chance of collision
> >> is practically zero. That's good enough.
> >
> > Yes.  And this solution is actually practical on pure 64bit
> > archs only.  On 32bit and dual archs it's not practial, because
> > legacy apps (those compiled without largefile support)
> 
> First, we're not talking about legacy apps here.  The applications
> we're talking about all have largefile support, as do the vast
> majority of other applications that I use daily.  So if you come up
> with a solution that works well with largefile apps, and does
> something sort-of-reasonable for legacy apps, that's fine.
> 
> Second, even 32-bit hashes are pretty good.  The chances of their
> screwing up in practice are quite small, if you have good hash
> functions.

For a perfect 32bit hash function the chance of a collision in a set
of 10,000 files is approx. 1%.  The chance of a collision in a set of
100,000 files is approx 70%.  I have 470,000 files on my root
partition, the chance of a collision within that is for all intents
and purposes 100%.

It may not matter in practice, but it would be hard to call that POSIX
conforming, which _very_ clearly states that inode numbers are
_unique_.

> > This is not a theoretical
> > possibility, I've had bug reports in this area.
> 
> 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.  You are living in some
dream world I think, where the users serve the programmers, and not
the other way round.

> That's much better than asking people to rewrite thousands of apps.

I think you are the only one asking for that.

> (If you're getting lots of bug reports for legacy apps, then
> improve the quality of your 32-bit hash functions.  :-)
> 
> > Currently I have report of exactly 1 (one) application,
> > that breaks.
> 
> Sorry, that's not sufficient evidence.  I'm sure lots of other apps
> will break, but people won't necessarily know where to send the bug
> reports.

I'm not holding my breath for these bug reports, sorry.  Sshfs may be
a newcomer, but smbfs and fat has been around for quite some time.  If
they would break applications, those bugs would have been reported
already.

> There is a standard for this, a standard that reflects longstanding
> practice.

Which is what I have been doing.  Had I been using a hash function in
FUSE to get the inode number I would have been breaking long standing
practice.

> Just conform to the standard, and you'll be fine.

Neither uniqe-unstable or collinding-stable inode numbers conform to
POSIX.

Miklos