[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11844: du: continue processing after bind-mount induced dir-cycle
From: |
Jim Meyering |
Subject: |
bug#11844: du: continue processing after bind-mount induced dir-cycle |
Date: |
Mon, 02 Jul 2012 19:04:20 +0200 |
du and other fts-using tools like rm, chmod, chown, chgrp, etc.
must detect directory cycles. Such cycles can indicate disk corruption
or (when following symlinks) a merely-ignorable cycle.
There is also the issue of how these tools treat a bind-mount-induced
directory cycle. One might hope that du's --one-file-system (-x) option
would help you avoid bind-mounted mount points, but that's not
what "one file system" means.
Two years ago, this was discussed here:
http://lists.gnu.org/archive/html/bug-coreutils/2010-01/msg00011.html
Recently, the issue came up again here:
http://bugzilla.redhat.com/836557
where I outlined a solution:
I have been considering a fix for this:
- read+stat all mount points at start-up
For now, I would do this in du.c, not fts.c, since fts clients
like rm, chmod, chown, etc. are much less likely to be used to
process mount points in a recursive traversal. Eventually, this
could migrate into fts.c, and be enabled via a new option. Once
ls is converted to use fts, we would have two clients using the
new feature. We'd probably want to ignore stat failure.
- put each dev/ino pair in a small hash table
- for each regular (i.e., not XDEV) dir encountered while traversing,
if its dev/ino is in the hash table, emit a diagnostic, arrange
not to process its entries, and arrange to exit nonzero.
If someone is interested in implementing this, I'd welcome a patch.
- bug#11844: du: continue processing after bind-mount induced dir-cycle,
Jim Meyering <=