Trash mechanism

[Alexander Larsson]

On Wed, 2004-08-25 at 02:36, David Faure wrote:
> Hi there,
> 
> I'm about to rework the Trash handling in KDE.
> I managed to find the old conversation (*) where a few kde and nautilus
> hackers started discussing on the gnome-kde-list about a common format for 
> the data under ~/.Trash, but nothing came out of it (mainly because the Corel
> people who promised to implement it in kde, disappeared).
> 
> Is there some interest in a common standard for trashed files?
 
Certainly. In fact, trash-handling is one of the areas in
Nautilus/gnome-vfs that is most crufty atm and I've long wanted to do
something about it. 

> Could someone tell me if Nautilus uses some kind of metadata file already,
> to store the original location of the file, the date of deletion, the original mtime etc.?

No, but i've long wanted to have that so you can do "put back" on
trashed files. We do however move files to the trash instead of
copying them, so atime and mtime are not modified. 

> If not, how does it store the files currently, under the .Trash directory?
> Simply keeping the initial directory layout?

What we currently use is similar to what pavel describes at
http://mail.gnome.org/archives/gnome-kde-list/2000-December/msg00022.html,
but we simplified it to only look at the root of mountpoints instead
of searching for a place where we can write. The search for a writable
location just took to long time. 

gnome-vfs has a "find-trash-directory" function, which for file://
uris is implemented like this: 

 If file is on same mount as the homedir (calculated as lstat
 (file_to_be_trashed).st_dev == stat ($home).st_dev, the lstat/stat
 distinction is important here) we just return  $home/.Trash.  

 If the file is not on the homedir mount, we locate the top of the
 mountpoint by chopping off elements of the pathname until we find a
 path where lstat(path).st_dev != lstat(file_to_be_trashed).st_dev and
 use the path we looked at before that. [We cache trash-directory per
 st_dev, so this walk is not done all that often]  

 In the mountpoint directory of the mount we check for a .Trash-$user
 directory. If its not there and we're trashing a file we try to create
 it. 

At the moment no gnome-vfs backend other than file:// supports finding
a trash dir.

If a trash dir couldn't be found/created we deny trashing the file and
asks the user if they'd like to delete it instead. If a trash
directory was found we just move the file/directory to the trash
directory as-is.

When viewing the trashcan we locate all the trash directories
currently on the system and present a unified trash directory from this.

This approach has some nice properties, but also some bad ones. I'm
fine with switching to a different model if thats what we decide. I'll
try to point out some of the good and bad properties:

Good things about the current gnome-vfs approach:

* Finding the trash directory is fast
* Trashing a file, if possible, is an atomic, constant time operation
  that will never error out due to out-of-space or other issue. Even
  trashing large files is instant, which is important because the user
  don't expect trashing to be a costly operations, especially
  considering that most trash operations are never undone.
  The out-of-space handling is importang, because it solves the
  "trashing files to make space on a full disk" problem that you have
  if you copy files to the trash.
* separate user trash directories on non-homedir means there are no
  permissions problem with multiple users trashing stuff. All users
  will have write permission to their trash dir, and no other user
  look your trashed files or put stuff there.
* Having the trash directory on the actual removable media is nice
  because trashed files move with the media so you can undelete them
  from any machine and you can only see the trashed files for the
  currently mounted media in the trashcan (meaning you can't undelete
  files from a removed floppy).
  

Bad things about the gnome-vfs approach:

* We don't store the old location, so "put back" functionallity can't
  be implemented.
* It doesn't handle name collisions in a trash directory. You just
  can't trash two files with the same name on the same mount.
* If you trash a file with the same name on two different mounts the
  merged trash directory has two files with the same name. It still
  works, because internally it knows which file is from where, but it
  can look a bit strange in the ui.
* Since trash directories are not shared by everyone it is sometimes a
  bit hard to understand why a disk is full. The disk can be
  out-of-space because another user has trash on it, and yet your
  trashcan is empty. This is especially problematic on removable
  media.
* If you trash a directory you own, that contains a file that you
  don't have permissions to remove (say someone else owns it) you end
  up with files in the trash dir you can't get rid of, so "empty trash"
  stops working.
* The approach of storing trash on removable media has problems:
  - On non-unix system you see this strange .Trash-$user directory
  - On unix system the trash dir is hidden, and its not obvious that
    the media is not empty, because the connection with the files in
    the trash location is not very explicit, or even logical.
  - For many people its unexpected that if you remove some files from
    your floppy/compact flash/whatever and use the media somewhere
    else (camera, non-gnome machine, etc) the disk space that should
    have been freed is not availible. Its hard to understand why this
    happens, and sometimes it might even be hard to get rid of the
    trashed files.  
* For files in shared directories, for instance a directory used for
  people in a project, its unlikely that you have write permissions to
  the root of the mountpoint, so you can't trash files there, even if
  you have remove permission in the directory.
* The algorithm used to locate the trash directory for a file breaks
  in the case of devices mounted in multiple locations. The location
  you get depends on in which mountpoint the first trashed file on
  that device is on. Devices mounted in multiple places is possible in
  linux with --bind mounts, although their use is not that common.

    
Clearly, its not an ideal system, although I think the advantages of
using a system where trashing means just moving a file on the
partition are large enough that we can't consider not doing
that.

Looking at the list of problems, many of the hard-to fix
problems are related to removable media. What do other systems
(windows, mac, etc) do with trash on removable media? Maybe its good
enought to say that we don't support trash on removable media? (Of
course, its a bit hard to figure out whether a mountpoint is on
removable media in unix.)

I think there are four basic scenarious where a normal user would like
to remove a file and the trash system comes into play:
1) Removing a file in your homedir
2) Removing a file on a removable media (floppy, flash card, etc)
3) Removing a file on a custom partition the user set up on his own
   computer
4) Removing a file in a shared directory on some mountpoint (e.g. a
   project directory, often on a network mount)

In case 1, which is the most common and most important case moving
things to ~/.Trash or something like that works perfect. The hard part
is the others. Maybe a good solution is that we don't normally create
trash directories outside of the users homedir, but if an admin
creates a writable .Trash directory at the top of a mountpoint, we
create .Trash/$user directories in that. I think this works for case 3
and 4 (although requiring some setup for it to work). For removable
devices I think my opinion is really that we shouldn't be storing
trash on them, so not allowing trash there is probably a good thing.
   

> I found some info on the .Trash-$USER thing for other writable partitions,
> what's mainly missing is the metadata stuff, and how to organize things under 
> the .Trash directories (e.g. as suggested on
> http://mail.gnome.org/archives/gnome-kde-list/2000-December/msg00026.html)
> 
> (*) http://mail.gnome.org/archives/gnome-kde-list/2000-December/msg00022.html

Some of the metadata ideas here look ok to me.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an immortal Republican senator in drag. She's a sarcastic renegade 
research scientist fleeing from a Satanic cult. They fight crime!