Trash mechanism

[David Faure]

Hello Alexander,
thanks for the detailed answer!

On Wednesday 25 August 2004 15:32, Alexander Larsson wrote:
> > 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. 

In fact even if we move files between partitions we can preserve atime/mtime
(people who use vfat for their $HOME don't count :). So OK, no need for
mtime there either (this was also the conclusion of the old discussion: better
not define a complete redundant filesystem, so we should store as little
metadata as possible, which currently seems to be only
- original location
- original filename [see bottom of mail]
- date of deletion

> > 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. 
OK.

> gnome-vfs has a "find-trash-directory" function, which for file://
> uris is implemented like this:  [...]
Thanks for the details.

> 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.
This is something I plan to do differently in KDE;
I have a different opinion on http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=78671
and it's that 
1) if there's no way to move to a directory on the same partition (no permission),
or it doesn't make sense to do so (e.g. removeable media, as you pointed out)
2) and there's enough space in $HOME/.Trash,
then we should move the file, even though it's across partitions.

But we don't have to agree on what the user experience should be,
only on the location and contents of the trash-can directories :)

> When viewing the trashcan we locate all the trash directories
> currently on the system and present a unified trash directory from this.
Yes. trash:/ ? The URI-discussion is another one, but maybe we can
even agree on a uri scheme here. OTOH it doesn't matter much, people
are not going to exchange trash uris :)

> * 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.
One thing users expect even less, is to see the software refusing to do
what they asked for - in cases where it's actually possible :)

I mean, I even saw people requesting "trashing" files from remote filesystems.
Yeah, we both know people request weird stuff, but still :)

>   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.
Well that actually works if you copy files to $HOME, unless $HOME is where
you're trying to make more room in the first place :)
Other than that, well, I can always error out on ENOSPC and the user has
to delete instead of trashing. Out-of-disk-space isn't usually the everyday
case; on the other hand files from other partitions are pretty common.
But as I said - we don't have to actually agree on that. It's just good to
discuss the pros and cons of the various solutions here, even if we
choose a different one.

[...]
> * 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.
I was planning to disambiguate files using file[1].txt file[2].txt or whatever.
Well, that doesn't really help the user much; it's merely a necessity so
that the file items have different URLs.

> * 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.
That one is pretty nasty. OTOH the same would happen when trying to
delete (rm -r) the directory in the first place. Checking for this at
"trashing" time might be better for the user experience, but otoh it might
take a long time when trashing a huge directory...

> * 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.  
Yes. I'm not convinced about storing trash on removable media.
I'd rather let the "trash" operation move files to $HOME/.Trash in such
a case.

> * 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.
Same there.

> * 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.
Hmm. Yeah. We use another method of finding the mountpoint for a
given directory (and the associated device) in KDE: by parsing mtab.
That's got to be slower, of course... OTOH with proper caching (like you do
too) it might not matter much.
    
> 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.
Moving on the same partition is of course the best case. That doesn't
mean we shouldn't also make the less trivial case work when possible
(enough disk space).

> 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? 
I just checked using a USB key on a friend's laptop, and Windows actually
doesn't allow trashing files from it, only real deletion. I guess it really only 
allows moving to trash from local partitions.

> Maybe its good enought to say that we don't support trash on removable media?
If you really don't want to move files to $HOME/.Trash, then yes. Personally I
don't see a reason not to do that.

> (Of course, its a bit hard to figure out whether a mountpoint is on
> removable media in unix.)
Yes (mtab parsing can help there too)

> ...  but if an admin creates a writable .Trash directory at the top of a mountpoint, we
> create .Trash/$user directories in that. 
That sounds like something nobody will think about doing....
I don't really see a problem with auto-creating those dirs on non-removeable
media. But, hmm, maybe people who don't like such "pollution" might want to
turn it off, could be a checkbox option (using move-to-$HOME if disabled).

> Some of the metadata ideas here look ok to me.
Good :)

The main remaining question is the directory layout under ~/.Trash
The idea of having info/ (with the metadata files) and files/ (with the actual files
or directories) sounds good for several reasons:
* easy transition for you - hmm, ok, except if the user has already deleted an
info or files directory :/
* separating metadata and actual user files/dirs, obviously.
I don't see a need for the tmp/ subdir that was proposed in the mail I linked to,
we have a mechanism for creating tempfiles in an atomic way already. But the
other good thing about using subdirs (and leaving ~/.Trash itself without files)
is that one can easily use any additional subdirs if wanted.

The metadata/ subdir would contain files with a generated name (any scheme
is ok, the filename really doesn't matter from an interoperability point of view)
containing the following three lines:
<original location>  (path, or optionally URL if we really want to have support for deleting from remote directories)
<original filename> (see below)
<date/time of deletion> (ISO 8601 format, i.e. YYYY-MM-DDThh:mm:ssZ)

The files/ subdir would contain the deleted file or directory, using the same
generated filename as the one used in metadata. It's important to specify that
acquiring a tempfilename MUST be done in the metadata/ subdir first, to avoid
the obvious race condition here.
We can't just keep the initial filename since this would not make it possible to
have multiple deleted files with the same name, so let's use the same tempfilename.

A thought about deleting directories: we only need metadata for the toplevel directory.
Then we can move the directory to files/, and even if the user wants to restore
a single file under there, we have all the medata: it can be deduced from the metadata
for the toplevel directory.

How does that sound?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).