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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
