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