How are loopback devices related to nautilus?

Its described in the related issue.

Although I don't think that escalation from IT to BZ is working - I escalated
this from IT to BZ and it doesn't seem to have done anything except copy the
title of the IT.

Any clues on how to get the escalation to actually work properly?

There is no reference to an IssueTracker number that i can see, and i don't have
an IssueTracker account. Nor am i supposed to need one i've been told.

Obviously a feature :-)

Cut and paste from the IT below:

 Running RHEL2.1ES will all updates applied:

losetup-2.11g-6
mount-2.11g-6
kernel-smp-2.4.9-e.49

We find that after mounting filesystems loopback, and then unmounting, the loop
device is not being freed. This causes us to eventually run out of loop devices
which means the machine must be rebooted.

Output of lsof:

[root@cslx1013 root]# for I in /dev/loop* ; do losetup $I ; done
/dev/loop0: [0809]:18 (RedHat_ES2.1u4-disc1.iso) offset 0, no encryption
/dev/loop1: [0809]:19 (RedHat_ES2.1u4-disc2.iso) offset 0, no encryption
loop: can\'t open device /dev/loop10: No such device
loop: can\'t open device /dev/loop11: No such device
loop: can\'t open device /dev/loop12: No such device
loop: can\'t open device /dev/loop13: No such device
loop: can\'t open device /dev/loop14: No such device
loop: can\'t open device /dev/loop15: No such device
/dev/loop2: [0809]:22 (RedHat_ES2.1u4-disc3.iso) offset 0, no encryption
/dev/loop3: [0809]:22 (RedHat_ES2.1u4-disc3.iso) offset 0, no encryption
/dev/loop4: [0809]:17 (RedHat_ES2.1u4-dvd.iso) offset 0, no encryption
/dev/loop5: [0809]:18 (../RedHat_ES2.1u4-disc1.iso) offset 0, no encryption
/dev/loop6: [0809]:19 (../RedHat_ES2.1u4-disc2.iso) offset 0, no encryption
/dev/loop7: [0809]:22 (../RedHat_ES2.1u4-disc3.iso) offset 0, no encryption
loop: can\'t open device /dev/loop8: No such device
loop: can\'t open device /dev/loop9: No such device

Trying to free these devices with losetup -d results in:

ioctl: LOOP_CLR_FD: Device or resource busy

 Further investigation shows that the open file handles are being kept open by
nautilus:

lsof | grep loop:

nautilus   8037    root   15r   BLK        7,0              66789 /dev/loop0
nautilus   8037    root   16r   BLK        7,1              66790 /dev/loop1
nautilus   8037    root   17r   BLK        7,2              66797 /dev/loop2
nautilus   8037    root   21r   BLK        7,3              66798 /dev/loop3
nautilus   8037    root   22r   BLK        7,4              66799 /dev/loop4
nautilus   8037    root   23r   BLK        7,4              66799 /dev/loop4
nautilus   8037    root   24r   BLK        7,5              66800 /dev/loop5
nautilus   8037    root   25r   BLK        7,6              66801 /dev/loop6
nautilus   8037    root   26r   BLK        7,7              66802 /dev/loop7
nautilus   8056    root   15r   BLK        7,0              66789 /dev/loop0
nautilus   8056    root   16r   BLK        7,1              66790 /dev/loop1
nautilus   8056    root   17r   BLK        7,2              66797 /dev/loop2
nautilus   8056    root   21r   BLK        7,3              66798 /dev/loop3
nautilus   8056    root   22r   BLK        7,4              66799 /dev/loop4
nautilus   8056    root   23r   BLK        7,4              66799 /dev/loop4
nautilus   8056    root   24r   BLK        7,5              66800 /dev/loop5
nautilus   8056    root   25r   BLK        7,6              66801 /dev/loop6
nautilus   8056    root   26r   BLK        7,7              66802 /dev/loop7
nautilus   8057    root   15r   BLK        7,0              66789 /dev/loop0

etc.

Restarting nautilus frees the file handles and then allows us to use losetup -d
to free the loop devices.

This isn't a problem in RHEL4, and i'm pretty sure it doesn't happens in RHEL3
either (it has some code to ignore loopback mounts). Its unlikely we'll spend
any time on fixing this for AS 2.1 at this time, since this is the very old
gnome 1.4 desktop, so i'm gonna just close this as CURRENTRELEASE.