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 freedesktop.org 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.