--- Begin Message ---
Subject: |
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.
--- End Message ---
--- Begin Message ---
Subject: |
Re: du bogus warning with bind mounts |
Date: |
Tue, 21 Aug 2012 22:24:05 +0200 |
Jim Meyering wrote:
> [Re: http://bugs.gnu.org/11844
> du: continue processing after bind-mount induced dir-cycle ]
>
> Ondrej Oprala wrote:
>> Sure, that looks great. Thanks for the help.
>
> I added this to the log:
>
> * THANKS.in: Update.
> This implements the proposal in http://bugs.gnu.org/11844.
> Originally reported in http://bugs.debian.org/563254 by Alan Jenkins
> and more recently as http://bugzilla.redhat.com/836557
>
> and pushed:
> http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=cf7e1b5b8fb53aef2a9103a32
The "du"-related part of this bug is now resolved,
so I'm marking it "done".
As I mentioned in the proposal, http://bugs.gnu.org/11844:
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.
Which means until ls.c is converted to use fts.c (a big job)
there's little point in trying to move this functionality into fts.c.
--- End Message ---