Mikulas Patocka <address@hidden> 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).