Mikulas Patocka <[EMAIL PROTECTED]> wrote: ... >> There are a lot of packages that will break (sometimes subtly) on file >> systems that lack stable file serial numbers: coreutils, diffutils, >> git, tar, the list goes on for quite a ways. I'm afraid the only >> current answer to this problem is "don't do that then". >> (I'm quoting Linus Torvalds in <http://lkml.org/lkml/2005/4/8/236>.) > > So tell users not to do it. How should they otherwise find? > > The most scary thing is that these filesystems most-time work and break > randomly, when inode numbers colide.
For people who care about robustness, this is a good argument for avoiding those file systems. However, let's be more precise. These file systems do not reuse i-node numbers "randomly", but rather only under extreme memory pressure, and then only for files that are not in use. That said, copy.c could be implemented in a way that would work better in the face of those constraints. Such a rewrite would be welcome also for the fact that it would eliminate the current PATH_MAX limitation. Volunteers welcome :) Same for ls.c. > Would you really dare to accept a patch that prints > "cp: error, your filesystem is not posix compliant, to prevent possible > data damage, coreutils refuses to operate on it?" on non-conforming > filesystems? (AFS, SMB, CODA, FAT ...) > > Coreutils 5 used to work (at least if nlink == 1 they didn't care about > inode numbers), the new code in coreutils 6 to prevent directory loops > breaks on non-posix filesysmtes. coreutils-5.x even had support for systems with no inode numbers. However, since then, the bar has been raised: there were fundamental limitations associated with the chdir-based approach. Fortunately, I've been able to transition to a more robust approach that is also more efficient: use openat and the other *at functions -- it also permits a thread-safe remove.c. However, since we continue to support systems that lack native openat support, and since fts.c still supports the legacy non-fd interface, some bits of code are more convoluted. Luckily for most people, the coreutils-6.x programs work just fine, even on non-posix file systems. If you find a way to make a coreutils program malfunction consistently in an environment that's not _too_ contrived, please let us know. The ideal would be to provide a script that can be used as a non-interactive test case, to be run only on systems with required file system type and/or permissions (e.g., root). _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
