Le 07/04/2012 01:18, Rob Landley a écrit :
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.
Denys, what do you think about this? I agree with Rob here, not having
the loopback deleted by default is definitively confusing.
--
Florian
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
