Automatic deletion of loopback device upon umount?

[Rob Landley]

On 04/06/2012 01:20 AM, ralda at gmx.de 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 <vda.linux at googlemail.com>
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.