On 04/06/2012 01:20 AM, [email protected] wrote: > Hi Florian ! > >> 1) loopback mount "foo" to mount /bar >> 2) umount /bar >> 3) append new files and re-generate the "foo" cramfs image >> 4) loopback mount "foo" to mount /bar >> 5) the contents of /bar are the same as in 1) and not 3) > >> Obviously using umount -d in 2) fixes the issue, but I was wondering >> whether it would not be preferable to unconditionnaly delete the >> loopback device upon umount? util-linux does this actually, so other >> users might also be puzzled by such a case. > > I hit that too, some time ago, not cramfs but squashfs and ISO images. > That was the reason I added an "alias umount='umount -d'" to > my /etc/profile and added the "-d" to all umounts in scripts. > > IMHO it would be better to reverse definition of the "-d" option to > umount and do NOT delete the loop device if option gets specified and > drop/delete it in the default case.
You mean the way I originally wrote it before this commit broke it? b2e578a1f2c3cf317b391a7d2c059d6a5f5368b8 is the first bad commit commit b2e578a1f2c3cf317b391a7d2c059d6a5f5368b8 Author: Denis Vlasenko <[email protected]> Date: Thu Feb 14 12:00:21 2008 +0000 umount: instead of non-standard -D, use -d with opposite meaning (closes bug 1604) I have no idea what bug 1604 was, but leaking loopback devices was wrong. I had code to automatically clean them up, it ran by default, and now it doesn't. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
