On Sat, 30 Dec 2006, Jim Meyering wrote:
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.
There are two separate issues on this: changing ino_t (which is
unavoidable on FAT) and non-unique ino_t (which is unavoidable on CODA).
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).
I don't have time to write it now, but the reproducible way for cp failure
on FAT on Linux could be:
create directory tree with many small files
use cp -a on that tree
stop it
run other unrelated big program (no touching the tree at all -- just
allocate memory to remove inodes from cache)
resume cp
--- if the files are small, the probability that cp is stopped after
stat and before open could be non-infinitesimal.
BTW. could it be possible to change POSIX on this issue? (i.e. specify
that general file manipulation tools must work on foreign non-posix
filesystems, specify a statvfs flag meaning that filesystem has
colliding/unstable inode numbers) Is it bureaucraticly achievable? ---
standarts should be done to support reliable operation but it looks like
this ino_t uniqueness does just the opposite.
Mikulas
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
