> >> 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 _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
