Miklos Szeredi <[EMAIL PROTECTED]> writes: >> 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. But even if you disagree with me, and want to implement some other solution for small-file apps that would cause small-file GNU 'find' to break, then that's OK. GNU 'find' is not compiled in small-file mode. Just get the filesystem to work in largefile mode, and leave GNU 'find' alone. (Similarly for GNU coreutils, etc.) >> That's much better than asking people to rewrite thousands of apps. > > I think you are the only one asking for that. The issue in question is much larger than GNU 'find'. It applies to many programs that use gnulib, and it applies to many other programs that don't use gnulib. There's no way we're going to rewrite them all, particularly if the rewrites make the programs less secure on file systems that conform to the standard. > I'm not holding my breath for these bug reports, sorry. It's better to take a proactive approach, and fix buggy areas when warned about them, before users find out about them; particularly when the failure mode is so obscure, as it will be here. >> 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? _______________________________________________ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-findutils
