Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020712 Description of problem: If I use nautilus to "delete" (move to trash) a file on a zip disk, then I can't unmount the disk. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. start gnome/nautilus 2. mount a zip disk 3. create a file on the zip disk: [grover@slick grover]$ touch /mnt/zip/fubar 4. use nautilus to delete the file -- open nautilus window, navigate to zip disk, select file "fubar", hit delete key or right-click and select "move to trash" 5. close the nautilus window & try to unmount the zip disk from xterm: [grover@slick grover]$ umount /mnt/zip/ umount: /mnt/zip: device is busy right-click the zip drive icon on the desktop & select eject: I get a pop-up window which says: "Nautilus was unable to unmount the selected volume." If I click on the details button on this window, I get a message: "umount: /mnt/zip: device is busy." right-click on the desktop, and select disks->zip drive: I get the same thing, a pop-up window which says: "Nautilus was unable to unmount the selected volume." If I click on the details button on this window, I get a message: "umount: /mnt/zip: device is busy." 6. sure enough, there is an open file: [root@slick grover]# /usr/sbin/lsof | grep "/mnt/zip" fam 8450 grover 18r DIR 22,4 2048 97602 /mnt/zip/.Trash-grover 7. If I delete the .Trash* directory: [grover@slick grover]$ rm -r /mnt/zip/.Trash-grover/ then I am sometimes able to unmount the zip drive, but sometimes an open (deleted) file still shows under lsof: [root@slick grover]# /usr/sbin/lsof | grep "/mnt/zip" fam 8450 grover 18r DIR 22,4 2048 97602 /mnt/zip/.Trash-grover (deleted) Actual Results: see above Expected Results: I should be able to use nautilus to browse & delete files on a zip drive and then be able to unmount & eject the zip drive. Additional info: 1. The zip drive on this system is a removable ide zip drive, mounted in a Dell latitute c800 laptop. I have no idea if the same thing happens with other types of zip drive (pp, scsi, usb). 2. I can "solve" this problem by disabling fam: [root@slick grover]# /sbin/chkconfig sgi_fam off though, oddly, nautilus seems to think that it requires fam: [root@slick grover]# rpm -e --test fam error: Failed dependencies: libfam.so.0 is needed by (installed) gnome-vfs2-2.0.1-2 libfam.so.0 is needed by (installed) kde2-compat-2.2.2-7 fam is needed by (installed) nautilus-2.0.1-3 3. Suggested solutions: nautilus shouln't move "deleted" files into a .Trash* directory on removable media, or fam shouln't monitor .Trash* files.
Alex this is a longstanding issue, is it Nautilus or FAM doing the wrong thing?
That depends on what you mean. FAM always needs to keep a file descriptor open in a directory with watched files. But the real issue is that Nautilus monitors the directory. Apparently the trash directory. I think it needs to monitor all trash dirs to handle trash full/empty and stuff like that.
Alex can you look at this one? Seems to be one of the most important nautilus bugs open.
Looking at the code it seems like it should try to remove the monitor on the trash dir before unmounting when unmounting from nautilus. There must be some bug preventing this.
This should be fixed in 2.0.5-4
Fix confirmed with nautilus-2.0.6-1. You still have to wait a couple of moments after deleting the file to unmount the volume, but it does work now.
The fix has issues ... see bug 73125, bug 73126. Bill indicates that these appeared between 2.0.5-3 and 2.0.5-4
*** Bug 73125 has been marked as a duplicate of this bug. ***
*** Bug 73126 has been marked as a duplicate of this bug. ***
And now, after rebooting with 2.0.6-1, it's working again. :/
notting, how did you reproduce that error. It looks like it gets several volumes in the hashtable, but that should only happen if you have two mounts with the same mount path and device path. Very strange. I wasn't able to reproduce your asserts with a floppy.
Could it be caused by slow or failing mounts - porkchop was hosed last night and I was seeing these asserts.
Can you reproduce it today?
I'm not in the office today...
I tried to bring my nfs server up and down, but i still couldn't get those asserts.
Alex, my theory is that in nautilus-trash-directory.c:get_trash_volume where we have this: if (*trash_volume != NULL && (*trash_volume)->real_directory != NULL) { return FALSE; } we also need to check for a PENDING async job to fill in real_directory, and return FALSE if one is pending already. What do you think?
(The reason is that there are several paths to calling add_volume, and if finding the trash dir is slow, more than one could happen before we find the trash dir.)
Created attachment 74569 [details] proposed patch
Patch built into nautilus-2.0.6-5
That's what i guessed too, but i couldn't find the multiple ways that would trigger it. But the patch should be safe.
Things are still looking good with nautilus-2.0.6-6.
Still happening in nautilus 2.2.1-5 on RH9. The exact same thing as described in this bug. Should I open a new bug?
Nah, i'll just reopen this one.
I think this is likely fixed in fc3 with gamin. Closing for now. If you see anything like this in fc3test3 or later, please open a new bug with full details.