emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#11844: closed (du: continue processing after bind-


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11844: closed (du: continue processing after bind-mount induced dir-cycle)
Date: Tue, 21 Aug 2012 20:25:02 +0000

Your message dated Tue, 21 Aug 2012 22:24:05 +0200
with message-id <address@hidden>
and subject line Re: du bogus warning with bind mounts
has caused the debbugs.gnu.org bug report #11844,
regarding du: continue processing after bind-mount induced dir-cycle
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
11844: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11844
GNU Bug Tracking System
Contact address@hidden with problems
--- 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 ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]