Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 70667 - can't unmount zip disk
Summary: can't unmount zip disk
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nautilus
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Jay Turner
URL:
Whiteboard:
: 73125 73126 (view as bug list)
Depends On:
Blocks: 67217
TreeView+ depends on / blocked
 
Reported: 2002-08-03 15:57 UTC by Need Real Name
Modified: 2015-01-07 23:58 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-05 13:39:27 UTC
Embargoed:


Attachments (Terms of Use)
proposed patch (deleted)
2002-09-03 01:23 UTC, Havoc Pennington
no flags Details | Diff

Description Need Real Name 2002-08-03 15:57:04 UTC
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.

Comment 1 Havoc Pennington 2002-08-07 20:45:56 UTC
Alex this is a longstanding issue, is it Nautilus or FAM doing the wrong thing?

Comment 2 Alexander Larsson 2002-08-08 08:39:16 UTC
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.


Comment 3 Havoc Pennington 2002-08-21 16:53:02 UTC
Alex can you look at this one? Seems to be one of the most important nautilus
bugs open.

Comment 4 Alexander Larsson 2002-08-27 15:45:18 UTC
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.


Comment 5 Alexander Larsson 2002-08-28 15:04:14 UTC
This should be fixed in 2.0.5-4

Comment 6 Jay Turner 2002-08-30 18:17:58 UTC
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.

Comment 7 Owen Taylor 2002-08-30 23:56:53 UTC
The fix has issues ... see bug 73125, bug 73126. Bill indicates that these
appeared between 2.0.5-3 and 2.0.5-4

Comment 8 Owen Taylor 2002-08-30 23:57:24 UTC
*** Bug 73125 has been marked as a duplicate of this bug. ***

Comment 9 Owen Taylor 2002-08-31 00:00:43 UTC
*** Bug 73126 has been marked as a duplicate of this bug. ***

Comment 10 Bill Nottingham 2002-08-31 00:34:29 UTC
And now, after rebooting with 2.0.6-1, it's working again. :/

Comment 11 Alexander Larsson 2002-08-31 09:16:55 UTC
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.


Comment 12 Havoc Pennington 2002-08-31 15:15:51 UTC
Could it be caused by slow or failing mounts - porkchop was 
hosed last night and I was seeing these asserts.

Comment 13 Alexander Larsson 2002-08-31 16:11:32 UTC
Can you reproduce it today?


Comment 14 Havoc Pennington 2002-08-31 16:45:55 UTC
I'm not in the office today...

Comment 15 Alexander Larsson 2002-09-02 12:07:18 UTC
I tried to bring my nfs server up and down, but i still couldn't get those asserts.


Comment 16 Havoc Pennington 2002-09-03 00:54:46 UTC
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?

Comment 17 Havoc Pennington 2002-09-03 01:08:10 UTC
(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.)

Comment 18 Havoc Pennington 2002-09-03 01:23:09 UTC
Created attachment 74569 [details]
proposed patch

Comment 19 Havoc Pennington 2002-09-03 03:31:37 UTC
Patch built into nautilus-2.0.6-5

Comment 20 Alexander Larsson 2002-09-03 06:31:21 UTC
That's what i guessed too, but i couldn't find the multiple ways that would
trigger it. But the patch should be safe.


Comment 21 Jay Turner 2002-09-04 12:03:58 UTC
Things are still looking good with nautilus-2.0.6-6.

Comment 22 Don Himelrick 2003-06-14 13:44:43 UTC
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?

Comment 23 Alexander Larsson 2003-07-04 12:37:55 UTC
Nah, i'll just reopen this one.


Comment 24 Alexander Larsson 2004-10-05 13:39:27 UTC
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.



Note You need to log in before you can comment on or make changes to this bug.