GNOME Bugzilla – Bug 171073
Main trash icon in nautilus does not reflect trash contents on external volumes
Last modified: 2005-11-23 20:13:05 UTC
I have my normal FreeBSD filesystem mount, for which the trash can operates as expected. I also have a FAT32 mount on a separate drive. Dragging an item on the FAT32 mount creates the trash at /mountpoint/.Trash-username, but the main trash icon on the Desktop does not reflect the contents. The icon doesn't change, and the files don't appear in the Trash Can on the desktop. The only way to delete files on an external volume after dragging them to the trash can on the desktop is to rm(1) them manually, or browse to /mountpoint/.Trash-username and delete them from within there. The expected behaviour would be that the nautilus Trash Can should reflect .Trash-username contents on every mountpoint. I doubt this is a FreeBSD-specific issue. I'm marking the operating system as "All", because I believe this problem would appear on other systems. If people cannot replicate this on Linux, I'll change the operating system to "FreeBSD". This has been reproduced by other members of the FreeBSD GNOME team, with GNOME 2.8 and GNOME 2.10.
Is this a duplicate of bug 171073?
This may also be a GNOME-VFS/FreeBSD issue.
Please double-check that potentially duplicate bug number ;;)
If you mount, for example, a remote network drive, and delete a file on it, does it appear in your trash can? Does the file get moved to /the/remote/drive's/mount/point/.trash/? I don't have anything that I can test that on ATM.
Adam: Maybe you can start a debugger and check whether nautilus_trash_monitor_add_new_trash_directories gets called?
I have the same bug on x86/ubuntu hoary. This makes nautilus unusable to manage e.g. usb sticks, digital cameras and mp3players (which present as simple usb-drives to the computer). Steps to reproduce: 1. My wife plugs in her mp3player to shuffle around its contents. 2. She deletes some big file by dragging it to the trash (she wants to delete it directly but can't see any way to) 3. She discovers the disk is still full. 4. She asks me what the hell is going on. I tell her to empty the trash. 5. She empties the trash -- the icon shrinks. The USB drive is still full. 6. I ssh over to her machine and look around -- ~/.Trash/ is empty, /media/usb0/.Trash-katharine/ is still full. The only way to free up the space is with rm -rf /media/usb0/.Trash-katharine/ Note that if you take me (ubergeek) out of the situation, my wife can't use nautilus to manage her media player / camera / usbsticks / what have you. It sounds from the comments like this may be a rare case / hard to confirm. Is this true? Please let me know if so and I can try to get you more details on my setup.
What a horrible story. Raising priority.
This happens to me on volumes that are not unmounted except when the system goes down. I'm running Fedora Core 4 GNU/Linux at the moment and I've just sent a bunch of files from a subdir of my homedir into the trash by selecting the files in Nautilus then hitting Delete. The files go to the trash but the trash icon on the panel is not updated to show that there is something in the trash. If you look at the icon, you would never know that the trash has lots of deletable files in it. Even when I open the trash folder and see that there are files in it waiting to be deleted, the trash icon is not updated. Perhaps some updating could be done when certain events occur like sending a file to the trash, opening or closing the trash window, logging in, or perhaps using inotify-like functionality to check the trash dirs and do the icon updating based on what is learned about the content of the directories?
I'm sorry for filing 2 entries so close together but I just noticed something I don't see listed in this bug. I use Clearlooks as my window and icon style and the Nautilus trash window has a miniature trash icon in the left corner of the titlebar. This icon is correctly reflecting the state of the trashcan. The icon in the panel is incorrect.
> The files go to the trash but the trash icon on the panel is not updated to show > that there is something in the trash. If you look at the icon, you would never > know that the trash has lots of deletable files in it. The worst part about this bug is that the files AREN'T deletable. Because the Trash Can does not acknowledge those files, it does not delete them. When a user deletes a file (and empties it from the trash), he is trusting that the file no longer exists. With things how they currently are, sensitive data are not being deleted from the system. In fact, aside from choosing to delete by bypassing the trash can, there is no way for a user to legitimately remove sensitive data from his computer using GNOME! For this reason, I suggest raising the Severity to Critical, or even Blocker.
Hi I believe that I am experiencing another effect of the same bug. On my system the /home folder is a seperate partition. After installing the 2.12 gnome beta I couldn't use the trash. That is if I moved something to trash, it would go to ~/.Trash, but it wouldn't show up in trash: and the trash icon on the desktop and the trash applet remained empty. After reading this bug, I made myself a new home dir on the same partition as my root volume. In this new single partition setup the trash can worked.
I am seeing the same problem in 2.11.90, files sent to trash don't show up on the trash folder nor does the icon update. The only way to remove the files is to rm them.
I'm not seeing an improvment with a single partition file system, but if this really is the issue, it may have to do with Federico's gnome-vfs uri canonicalization patch.
CVS right now seems to work
Still doesn't work for me (CVS 2005-08-26). Still works when I use one partition. If I browse to a trash dir (like ~/.Trash) and right click a file, the first option is "Delete from trash" even though I am not at the trash: URI Discovered that trash works properly when hal is not running.
Trash works properly if hal is not running, or if it is running but gnome-vfs can't connect to it (for example, if you are using jhbuild, gnome-vfs looks for /home/foobar/jhbuild_install_dir/var/run/dbus/system_bus_socket, and fails). It works in that case because gnome-vfs falls back to using normal file monitoring. JRB reported that it works for him when running with HAL in Rawhide. It doesn't work for anyone when running HAL in Suse 10. Nautilus's trash monitor initializes itself by doing gnome_vfs_volume_monitor_get_mounted_volumes(), and then finding the trash directory for each volume. However, when it calls that on my Suse 10 machine, it *doesn't* get volumes for mounted partitions (/home, for instance). I've narrowed it down to this: When gnome-vfs-daemon starts up, it doesn't ever call _gnome_vfs_volume_monitor_mounted() for the volumes which represent my partitions. That function puts the volume in the list of volumes which will be then sent to client programs (i.e. those that call gnome_vfs_volume_monitor_get_mounted_volumes()). At that initialization stage in the daemon, that function can get called like this: gnome_vfs_volume_monitor_daemon_init() _gnome_vfs_hal_mounts_init() _hal_update_all() _hal_add_volume() _gnome_vfs_volume_monitor_mounted() <----- here update_mtab_volumes() _gnome_vfs_volume_monitor_mounted() <----- here In the first case, hal doesn't even pick up the volumes for the partitions. In the second case, the partitions get picked up from mtab, but are *not* added as volumes since gnome-vfs cannot find their UDIs among the drives. I'd love some help in diagnosing why hal doesn't notice the partitions. This is hal 0.5.4 and gnome-vfs 2.11.92.
Hi, So after looking at this today with Federico it appears that the problem is that the hal backend makes the mistake of not adding a drive/volume if it fails the policy checks. For instance, this means that the drive/volume for e.g. /home or /usr is not added since we don't want to show an icon for this location. The correct behavior, if policy checks fails, is to still add the drive/volume but set the is_user_visble flag to FALSE. I am right now working on a patch to fix this.
This problem cannot be related to HAL, or cannot be only related to HAL, because the bug is reproducable on FreeBSD, and FreeBSD does not have HAL support.
Adam: Sorry, I think this bug went slightly off on a tangent. Your bug is "trash doesn't show up for external volumes", and we started discussing a more general problem, which is "trash doesn't show up for anything" :) I may be able to take a look at your specific bug (not on FreeBSD, unfortunately) when the general bug is fixed.
Adding to the 2.12 showstoppers list.
Created attachment 51595 [details] [review] Proposed patch for issues described in comment 17 This patch should fix most problems. I've disabled reprobing when gconf settings changed as this is slightly busted. New patch should improve the general uses though. Please test.
Patch from comment 21 seems to fix the problem I described in comment 11
The patch seems right to me. And this indeed an important fix. Davidz: are you gonna take this up with the release-team? maybe we need some more testing first.
Thanks a lot for the patch, David! I'll test it immediately.
Wheeee! The trash for my home directory works now. I'll test it with removable drives soon.
Federico, how did the testing with removable drives work out? It works for me, but I thought it would be nice with confirmation before I take the patch to the release team. Thanks, David.
David: go ahead with taking the patch with the release team. Removable drives are broken on Suse (that's what I'm using), but that's because Suse does Different(tm) stuff.
I need help from someone NOT running Suse to debug this further. After DavidZ's latest patch, the trash works for me in that Nautilus acknowledges all drives; I can delete stuff, even from removable volumes, and it will show up in the trash. However, when I unplug one of the removable volumes (a USB stick in this case), the Trash window doesn't reflect the fact that the volume is no longer plugged in. That is, the items which live in removable_volume/.Trash-federico still appear in the Trash window. If I click on them, they disappear. I'm not sure if this is a Suse-ism due to submount, or if it is a general problem. Can someone please confirm it? I'm more interested in people using a system install of GNOME 2.12, rather than jhbuild --- people who use jhbuild are very likely not to be using hal inside gnome-vfs.
I commited the patch, since it got r-t approval.
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.
Created attachment 51891 [details] [review] nautilus-171073-trash-unmount-removable-volume.diff With this patch, Nautilus removes the stale icons from the Trash window after I unplug my USB drive. However, it doesn't update the item count in the window - I don't know why it doesn't do that. If I re-insert the USB drive, however, I hit an assertion in nautilus-icon-factory.
Created attachment 51892 [details] Stack trace of the assertion failure This is the assertion that triggers. Does the icon cache fail to remove an item somewhere, or to ref an item? The refcount for the item in question is 0.
Eep, I may be hitting the (incorrect?) leak fix from bug #307288. I'll try again with an updated Nautilus.
For the uri list freeing, use eel_g_list_free_deep. Also, we always use brackets around all if-bodies. I'm slightly worried about the semantics of this. Doesn't removing the NautilusFiles from the merged directory like this also cause them to be removed if you view them in the real (non-merged) directory. OTOH, as things currently stand this will only be called in the case of a trash directory being unmounted, so it should be safe. The desktop doesn't use nautilus_merged_directory_remove_real_directory. I'm not sure if the beagle integration stuff uses this function, but it might.
Alex: I'll use eel_g_list_free_deep(); thanks for the pointer. I'll fix the braces as well. If you unplug the volume and the files also disappear from windows that are showing .Trash-username - well, that's what you wan't, don't you? :) Those windows should probably just disappear. The Beagle stuff doesn't use merged directories at all, as far as I can tell from the patch. BTW - Indeed I was hitting #307288. With an updated Nautilus, everything works fine with my patch. The only missing thing is updating the item count in the Trash window when you unplug the volume (oddly enough, the Trash icon in the desktop properly goes back to the "empty bin" icon). I'll look into this.
Created attachment 51936 [details] [review] Updated nautilus-171073-trash-unmount-removable-volume.diff Indeed, with a new Nautilus I don't hit the assertion failure. Sorry for the false alarm :) I'm pretty happy with the state of this patch. The only remaining thing is to make the Trash window display the correct item count in the status bar; I looked today into that works but got lost in a maze of idle handlers. How to duplicate this remaining bug: 1. empty your trash 2. plug in a USB stick or whatever 3. move a file in the USB stick to the trash 4. open the Trash window; note that it has a single icon and "1 item" in the status bar 4. unplug the USB stick 5. the icon disappears, but "1 item" remains in the status bar The thing is that update_status_idle_callback() gets called before display_pending_idle_callback(); this last function is the one who calls fm_icon_view_remove_file(). If I "rm" a non-trash file from the command line, I see update_status_idle_callback() happen after display_pending_idle_callback(). I'm not sure why there is a difference in this case.
federico: I agree it does what you want in the case of the trash. I was just worried about it being used in some other case, but I think we're fine here. So, the last patch looks good to commit.
Federico: > I'm pretty happy with the state of this patch. The only remaining thing is to > make the Trash window display the correct item count in the status bar; I > looked today into that works but got lost in a maze of idle handlers. This is very much related to bug 46200. Maybe the patch attached to that bug report helps? It isn't perfect yet and there are some nontrivial issues (cf. the associated mailing list thread). I don't remember the details, but I think "trash:" does not listen to invalidation or availability of updated deep count information for its merged directories. A simple callback which invalidates the information for "trash:" in response might do it.
Alex: thanks; I committed it. I'll mark this bug as fixed, and assign myself to bug #46200. Manny: Dude! Thanks a million for the pointer to that other bug! 2005-09-08 Federico Mena Quintero <federico@ximian.com> Fixes bug #171073: * libnautilus-private/nautilus-trash-directory.c (nautilus_trash_directory_instance_init): In addition to connecting to "volume_pre_unmount" on the volume monitor, also connect to "volume_unmounted". This will let the trash clean up its merged directory even if the unmount is not initiated from Nautilus. * libnautilus-private/nautilus-merged-directory.c (merged_remove_real_directory): When a real directory is removed from the merged directory, emit notifications to that effect. This lets the trash window remove the icons that used to correspond to a volume that got unmounted. (real_directory_notify_files_removed): New utility function.
Are you sure that what was committed fixes the originally reported bug here? From the ChangeLog there, it looks like a different problem got fixed. If the originally reported problem still exists, can you please reopen the bug?
I'm pretty sure this fixes your bug - the trash code wasn't properly monitoring the .Trash directories in removable media. This was not just a FreeBSD issue. Is general file monitoring working for you? I.e. if you 1. mkdir ~/foo 2. open a nautilus window for ~/foo 3. touch ~/foo/bar does the window update and show "bar" without you having to do an explicit refresh? If that works, then the trash should work now. If it doesn't, you have a bigger problem :)
I think that I'm stuck with a bigger problem then. :( Or this bug is back? I'm unsure. I've posted my experiece with it on the gentoo forums, thinking it a gentoo issue, here: http://forums.gentoo.org/viewtopic-p-2834189.html#2834189 Note that I am running really recent stuff (the gentoo "~x86" packages) and that my /home directories are located within my / partition. I wasn't sure if I should submit a new bug here, or post on this "solved" one, so I'll ask it to be reopened. (?) I'm completely baffled here. If this is not a true gnome bug, and is gentoo specific, my apologies. Otherwise, any help would be greatly appreciated!
Re comment #42: you didn't say what problem you are having.
Oh, my apologies. My problem is that trash:// isn't working, or displaying properly in Gnome. Here's the list of symptoms and such that I've found in trying to get this to work : * On the Gnome desktop the Trash icon (and panel applet for that matter) is always displaying empty. * Deleting a file from the desktop, or anywhere else, using the file browser places the deleted files in ~/.Trash * Similarly, dragging a file into the Gnome Trash icon places the file into ~/.Trash. * Opening the trash icon, or applet, or Trash "location" or "trash://" in the file browser shows it as always empty. * Deleted files do exist in ~/.Trash. * File-browsing ~/.Trash directly does indeed show the deleted files. (ala # ls ~/.Trash) * Double-click the Trash icon to browse it (empty) - I can drag-n-drop items into the browse window, and they are not displayed. (now reside in ~/.Trash) * This isn't a specific user's setting problem. I created a new-user (never touched gnome) and it behaved identically in Gnome. * I'm running all the latest and greatest gentoo ~x86 stuff: hal-0.5.4 dbus-0.36.2 gamin-0.1.7 gnome-vfs-2.12.1.1 nautilus-2.12.1 gnome-2.12.1 kernel ver. 2.6.14 (gentoo-sources) * I've tried rebuilding the above packages. I've done a revdep-rebuild as well (it changed nothing.) * Inotify is in my running kernel, and seems to be working just fine. ie, file-browsing a directory while creating/deleting a file within it from a terminal instantly shows it being created/deleted. (furthermore, Beagle works and displays new finds really quickly.) * Nautilus seems to pass all of its own internal checks: $ nautilus -c running nautilus_self_check_file_utilities running nautilus_self_check_file_operations running nautilus_self_check_directory running nautilus_self_check_file running nautilus_self_check_icon_container running nautilus_self_check_icon_factory running nautilus_self_check_file_utilities running nautilus_self_check_file_operations running nautilus_self_check_directory running nautilus_self_check_file running nautilus_self_check_icon_container running nautilus_self_check_icon_factory Again, my apolgies if this isn't posted in the correct place. I'm unsure if this is a bug specific to just myself, just gentoo, or to gnome in general. I thought that this thread was as close to what I'm experiencing as anything, so opted not to start a new bug. Thanks!
Does it work if you kill dbus/hal? This would make gnome-vfs fall back to the non-HAL code, which should work. [Killing it is not a solution; it's just to see where the problem may be] Also, you could try stepping with a debugger to see if gnome-vfs manages to contact HAL/dbus properly. Grep for "dont_use_hald" in the sources to see where that happens.