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