On 04/06/2012 03:41 AM, Florian Fainelli wrote: > Hi Harald, > > Le 04/06/12 08:20, [email protected] a écrit : >> 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. > I think this would be even more confusing, and make busybox no longer > conform to util-linux' behavior. I just sent a patch which just > unconditionally deletes the loopback device, so we have the exact same > behavior as util-linux' umount.
Back in 2006 I had umount: A) automatically de-losetup the loopback device by default. B) have a -D (capital D) option which disabled this behavior, so it was possible to umount a device _without_ clearing the loopback device, if that's what you wanted to do. I was pretty happy with this behavior at the time. Don't ask me how you can have a "nonstandard" implementation of something that isn't in SUSv4 (or any other standard I'm aware of)... 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
