Comment 44 for bug 548546

Ayan and I investigated this, and found out an interesting thing: When I explicitly use losetup/mount/umount/losetup -d as in comment 40, the aforementioned kernel patch [1] takes care to send a "change" uevent when the losetup -d happens.

However, when I use the approach that usb-creator uses, things still go wrong:

    sudo mount -o loop ~/download/ubuntu/natty-desktop-amd64.iso /mnt

This sends a "change" event on loop0 which causes udev/udisks/etc. to re-read the device, and see that there's an iso9660 file system on it.

    sudo umount /mnt

This does NOT send a change event on loop0, although it does tear down the loop device. So after that, udev/udisks (and thus the gvfs stack) still think that /dev/loop0 is a mountable iso9660 file system.

A workaround would be to poke the loop device in the usb creator backend:

     def UnmountFile(self, device, sender=None, conn=None):
         popen(['umount', device])
+ popen(['udevadm', 'trigger', '--verbose', '--sysname-match=loop0'])

Ayan is currently testing this.

But the proper bug fix would be to either fix umount to tear down loop0 "more properly" so that the kernel patch kicks in, or fix the kernel to also send a change event on the missing case that umount triggers if it unmounts a loop device that was mounted with "-o loop".

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c3473c63542d53740f175f3a515257ae159e998b