Fixing the Nautilus garbage bin again

Usability bugs are nasty, they tend to be a major point of frustration for novice users, yet their importance is sometimes hard to explain to developers.

An even worse situation occurs when such bugs, once worked around, come back to bite you in a later software release because of a lack of developer foresight.

I am going to discuss a work around for a bug I’ve already discussed in the past. I’m going to skip going into the details of how this bug arises, please read the previous post for those.

The reason we’re seeing this bug again now, in Ubuntu 8.04 (Hardy Heron) is that it includes Gnome 2.22 in which GNOME-VFS the file-system access layer was replaced with the new GVFS library.

GVFS brings along a number of welcome improvements, including better support for standards. However some of those improvements, notably the support for the “Trash Specification” , include changes to how data is saved to disk.

The problem arises because no care was taken to convert data already stored on upgrading user’s disk and bring it up to date with existing specifications.

In the previous post I’ve described a situation in which deleting file in Nautilus did not work properly on file-systems in which a required directory structure wasn’t created beforehand by the system administrator. I went on to describe how to create the needed structure thereby providing a work-around.

The reason this work-around no longer works is that the new “Trash Specification” defines new and incompatible structures describing where and how Trash-bin data is saved.

To work around the problem once again, the system administrator would have to run the following commands (assuming the problem file-system is mounted on /var/local):

sudo mkdir /var/local/.Trash
sudo chmod 1777 /var/local/.Trash

The tricky part to note here is the permissions set on the “.Trash” directory, those permissions, while allowing every user in the system to write to it, prevent users for messing with other user’s files.

Having created this “.Trash” directory Nautilus will go ahead and create a used-dedicated directory within it for each user as soon as that user tries to move a file in to the trash.

As discussed in the past, I’ve opened a bug requesting that more detailed information be presented to system administrators when encountering this problem (I find the way in which it is currently handled, e.g. suggesting to permanently delete the file, insufficient). Unfortunately that bug didn’t receive much attention in the past. I’ve seen renewed interest in it recently, however, so one may hope it will get addressed soon.


6 thoughts on “Fixing the Nautilus garbage bin again

  1. I had another partition mounted on (example) /usr/local/stuff/volume1. It was causing me two problems: Sometimes Nautilus would warn me that files could not be trashed and must be deleted, and sometimes it would create tons of little “.Trash-1000” folders scattered throughout the partition.

    Your blog and the one before helped me understand what was going on, and fix it. Although in my setup, I had to make another change before my problems were gone.

    The first problem was just that there was no volume .Trash directory in the root. OK, fixed! No more error messages about not being able to put stuff in the trash.

    But I was still sometimes getting .Trash-1000 directories scattered throughout the drive!

    Here’s what was going on: I had a symlink under my home directory to /usr/local/stuff which in turn contained symlinks with relative paths to /usr/local/stuff/volume1 . If I followed that path from my home directory in Nautilus and them deleted a file, it would still create little .Trash-1000 directories everywhere. But if I went directly to /usr/local/stuff/volume1 and deleted the same file, it would go in the volume trash.

    After reading up on the issue, I surmised that the issue was that GVFS was confused by the symbolic links, and “couldn’t find” the global trash directory on the mounted volume. When I changed my symbolic links so that they had absolute paths instead of relative paths, the problem went away and now all trash on /usr/local/stuff/volume1 goes into /usr/local/stuff/volume1/.Trash. Thank you!

    One nagging problem though. I still have to empty the trash on that volume “by hand” at the shell prompt because it doesn’t show up in my “real” trash can. I know there’s an open idea/bug/feature-request to integrate the trash cans across volumes, and it’s not done yet. But in the meantime, is there a way to create another trash-icon which will point to the other volume?

  2. Pingback: Bookmarks about Fixing

  3. Thanks. This was really difficult to find and Nautilus is not making it easier.

    I’m Having couple of NFS servers at home for storing different things and I do not like to see that things are permanently deleted. I’m not the only user…

  4. Pingback: Automatically mounting additional disks and fixing the Nautilus trash bin |

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s