Subject: bug#9472: rm --no-traverse-mount-points [Re: stop rm at same-dev bind mounts

From: Jim Meyering <[email-masked]>
Date: Sat, 10 Sep 2011 21:58:22 +0200

Thomas Moschny wrote:
> having a rm command accidentally removing 3/4 of my system yesterday,
> I am starting to wonder whether it is possible to have rm reliably
> stop at bind mounts. I know there is a --one-file-system option, but
> it is not working when the bind mount points to the same device:
>
> % cd /tmp
> % mkdir -p a/b c/d ; touch c/d/file ; mount --bind c a/b
> % find a
> a
> a/b
> a/b/d
> a/b/d/file
> % rm -rf --one-file-system a
> rm: cannot remove `a/b': Device or resource busy
> % find a
> a
> a/b
>
> `file' has been removed. Imho the name of the --one-file-system option
> is misleading as it only compares st_dev fields.

Thanks for the example, but I don't see how that option name is
misleading.  A "file system" is the thing you create with "mkfs".
Even though normally there is only one mount point per file system,
the fact that with bind mounts there can be many doesn't change
the name of the thing occupying the underlying device: a file system.

I think you want a new option, say --no-traverse-mount-points.

> Besides filing a
> bug/enhancement ticket for coreutils, does someone know a reliable way
> to stop rm in such cases?

It would tell rm -r not to cross any mount point.  Rm would have to be
able to read at start-up the set of all mount points, or maybe only
the mount points for a given device the first time a new device is
encountered.  Then, it could easily and efficiently test whether each
directory processed is in that set.

I've Cc'd bug-coreutils, so this message will create a ticket in the
issue tracker: http://debbugs.gnu.org/coreutils.