Bug 114914 - cannot empty trash can for removable media
Summary: cannot empty trash can for removable media
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Beta 3
Hardware: Other All
: P5 - None : Major
Target Milestone: ---
Assignee: Federico Mena Quintero
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-02 08:25 UTC by Ulrich Windl
Modified: 2005-09-08 20:02 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
nautilus-114914-trash-unmount-removable-volume.diff (1.14 KB, patch)
2005-09-06 01:07 UTC, Federico Mena Quintero
Details | Diff
Updated nautilus-114914-trash-unmount-removable-volume.diff (2.71 KB, patch)
2005-09-06 22:35 UTC, Federico Mena Quintero
Details | Diff
Another update for nautilus-114914-trash-unmount-removable-volume.diff (2.88 KB, patch)
2005-09-07 20:44 UTC, Federico Mena Quintero
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2005-09-02 08:25:53 UTC
When trying to copy a small file to my USB memory stick via drag and drop, I got
the message that there's not enough freespace (correct). So I used the popup to
move one large file from the stick into the trash can (icom animated to full
trash can). However when I tried to empty the trash can, the icon did not
change, and subsequent attempts to copy the file to the stick brought the same
"not enough space" message, even though there was enough space at that time.
Eventually copy per commandline succeeded.
So I guess there's something wrong with freespace caching and trash can
administration.
Comment 1 Danny Al-Gaaf 2005-09-02 08:40:38 UTC
looks like dublicate of 114473 
Comment 2 Ulrich Windl 2005-09-02 09:39:09 UTC
Inspecting .xsession-errors I found these "interesting" lines that might be related:
resapplet:15759): Glib-GObject-CRITICAL **:g_object_unref: assertion `G_OBJECT
(object)' failed
** (nautilus:15773): WARNING **: destroyed file still being monitored
Comment 3 JP Rosevear 2005-09-04 21:18:26 UTC
Federico has been looking at related removable media trash problems.
Comment 4 Federico Mena Quintero 2005-09-05 23:54:27 UTC
OK, the problem is that nautilus-trash-directory connects to
"volume_pre_unmount" in the master GnomeVFSVolumeMonitor only, but not to
"volume_unmounted".  It assumes that all unmounts will be initiated from
Nautilus itself.

When you unplug a USB drive, GnomeVFSVolumeMonitor gets notification from
gnome-vfs-daemon that a volume was unmounted.  Since this event was initiated
from the outside, it of course doesn't have a chance to emit the
"volume_pre_unmount" signal.
Comment 5 Federico Mena Quintero 2005-09-06 00:16:03 UTC
With a little patch to connect to "volume_unmounted", the trash window indeed
changes when I unplug the drive.  However, instead of the trashed files
disappearing, they just change their icons into the one corresponding to "no
icon for this file".  I guess something is wrong in nautilus-merged-directory or
thereabouts.  I'll keep looking.
Comment 6 Federico Mena Quintero 2005-09-06 01:07:44 UTC
Created attachment 48866 [details]
nautilus-114914-trash-unmount-removable-volume.diff

This is my patch so far.  With it, the Nautilus trash window notices that the
removable drive has been unplugged, but it doesn't refresh the icons properly. 
I'm tracing the code that does that.
Comment 7 Federico Mena Quintero 2005-09-06 22:35:45 UTC
Created attachment 49006 [details]
Updated nautilus-114914-trash-unmount-removable-volume.diff

With this newer patch, the Trash window  removes the stale icons.  It doesn't
update the item count in the window's status bar, however - I don't know yet
why it doesn't do that.

However, I get a crash if I re-insert the USB drive after pulling it out.
Comment 8 Federico Mena Quintero 2005-09-06 22:50:53 UTC
Uh, I may be hitting http://bugzilla.gnome.org/show_bug.cgi?id=307288 (this is
the Nautilus from beta2).  See the discussion in
http://bugzilla.gnome.org/show_bug.cgi?id=171073
Comment 9 Ulrich Windl 2005-09-07 07:31:01 UTC
Yesterday I found out that the ".Trash" folder on the memory stick also has the
username appended. For a media where the filesystem has no "owner" concept (like
FAT) this doe not make sense, as any user "having" the stick can delete
anything. It just wastes space.
Comment 10 Federico Mena Quintero 2005-09-07 20:36:09 UTC
About comment #9 - I agree, but that's more or less irrelevant to this bug. 
We'll fix that later.  Can you please file a bug for that, so that it doesn't
get forgotten?
Comment 11 Federico Mena Quintero 2005-09-07 20:44:33 UTC
Created attachment 49114 [details]
Another update for nautilus-114914-trash-unmount-removable-volume.diff

No functional changes from the last version of the patch, but this is in line
with the Nautilus coding style.  I haven't been able to find why the Trash
window doesn't update the item count in the status bar after the drive gets
removed.

[The assertion failre was a false alarm; with nautilus-2.12.0 this doesn't
happen anymore.]

See http://bugzilla.gnome.org/show_bug.cgi?id=171073#c36 for the details of the
incorrect item count.
Comment 12 Federico Mena Quintero 2005-09-08 19:42:47 UTC
OK, the Nautilus maintainer accepted my patch.  It is committed upstream now,
and should appear in nautilus-2.12.1.

I'll add the patch to our 2.12.0 package in the meantime and mark this bug as fixed.

This leaves the "wrong item count" to be fixed; that's
http://bugzilla.gnome.org/show_bug.cgi?id=46200
Comment 13 Federico Mena Quintero 2005-09-08 20:02:06 UTC
OK, submitted to autobuild.  You'll get this patch in nautilus-2.12.0-5 or later.