Trash mechanism

[David Faure]

On Thursday 26 August 2004 10:14, Alexander Larsson wrote:
> Well. Lets take a common situation such as removing all the files on a
> floppy, or in a more modern situation, a SecureDigital flashcard from
> your camera. 
> 
> Removing the files is just a metadata operation that is really fast.
> However if you copy files to a trash on another disk, this could
> potentially take a long time. Reading all the images from my SD card
> takes several minutes. Will the user really expect this normally fast
> operation to get a progress dialog and take several minutes to execute.

OK, I see where our difference of opinion on this comes from.
Nautilus offers only one "Delete" operation in the GUI, and tries to choose
the best way of deleting the file, either move-to-trash or real-delete.
Konqueror offers both "Delete" and "Move To Trash", so there's no problem
with handling removable media: the user can choose between "fast, real deletion"
and "slow, but safer move-to-trash operation which keeps a copy of the files
in $HOME/.Trash".

> > > 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 :)
> 
> Yeah, we use trash: here. However, its not currently implemented as a
> gnome-vfs backend, so only nautilus can use it. I'd like to change that
> though. Unifying the uri isn't extremely important as you say, but otoh
> it should be pretty obvious how to do, so we might as well try.

Yes, it should be quite simple. The only problem is handling duplicate filenames.
We can't use trash:/tempfilename for everything, since the ugly temp name would
appear when navigating into directories, or opening a trashed file (readonly) to
view it. But I delay the rest of that topic until the discussion on how to handle 
duplicates in the actual backend files.

> I'm pretty sure I'd hate using such an approach. Emptying is a very
> common operation on removable media (you do it every time you empty a
> digital camera and every time you need to use a floppy for something
> new), and it would be pretty slow. 
Not if you have the choice between trashing and deleting :)

> Of course one could expose both trash and delete operations in the ui
> and punt the problem to the user. That would work for people who already
> know this distinction and the pros and cons of trashing, but it would
> imho unnecessarily complicate the ui.
Well, it's good that we still will have a difference somewhere :)

> We do mtab parsing too, for instance to detect all mounted systems
> looking for trash directories. However experience has shown me that mtab
> parsing is a bit fragile, and its also not very portable (i.e. it needs
> lot of ifdefs). 
Yep. But now that it's there and debugged, I might as well use it :)

> I checked out what OS X does by testing my USB flashcard reader. It uses
> a way similar to Nautilus. When you trash something on the flash it
> creates a ".Trashes" directory on the root of the drive, and under that
> it creates a directory with the name being the uid of the user (I guess
> that makes some sense, especially on filesystems where you store the
> owner as a uid), where it stores the files as-is. 
Doesn't really help making room on the flashcard reader...

> Why do you store both original location and original filename in the
> metadata? Isn't the original filename just basename($original_location)?
Yeah this was stupid of me, I realized that when going to bed yesterday :-)
Let's drop the "original filename" field/line.

> You mention "generated name" for the tempfile, but in like 99% of all
> cases there won't be a collision, and i think using the real name is
> helpful if you ever manually look into the trash dir. If the real name
> doesn't work, using some algorithm like appending " (copy $n)" or
> something should work fine.
Hmm. In theory that's opening for race conditions (if multiple programs
try trashing a file with same name at the same time - this is because we'll 
be doing this in a kioslave, i.e. letting several programs benefit from this,
in particular kdesktop and konqueror initially). But of course since trashing
a file is a user-requested operation, he'd have to be pretty fast with his mouse :)

So, OK, why not. We still need to differenciate fileid and filename
though (I call fileid the name of the deleted file on disk, and filename the real
user-visible name, coming from original-location, and used when displaying the 
contents of the trash and restoring the file). 
But you're right, if the fileid is still "readable", then we'll have prettier URLs.

OK... Let's say we use the initial filename as id when possible.
~/.Trash/files/foo.png
~/.Trash/info/foo.png  (the text file with two lines in it)

(is it ok if I use info instead of metadata? we use the metadata term already for
something else in kioslaves and it will get confusing :)

Now if I delete another foo.png file, the internal id could be "foo (copy).png"
or "foo.png.2" or whatever - this doesn't need to be standardized indeed,
the ids don't matter. info/foo.png.2 would still say info.png in the original
location, so we can actually display that name when listing the trash, as long
as the url for the two files is different.
So the url scheme would simply be trash:/<fileid> and trash:/<fileid>/file1.txt
(and trash:/<fileid>/subdir/file2.txt etc.) if <fileid> is actually a directory.

The only downside of readable fileids is the risk of mixing up fileid and
filename during implementation, a risk that doesn't exist with tempfilenames :-)
(mental picture problem).

> What about filesystem operations in trash://? For instance, the names
> presented for the files shown in trash:// are not the real filenames, so
> if you rename a file then we can't rename the file. Should we instead
> rewrite the original filename/location in the metadata?
That could be done. Or we can simply disable renaming of trashed files.
People can rename the file _after_ restoring it anyway.

> What if you create a folder there, what do we set the original location to?
Creating things directly in the trash should simply be forbidden.

> What about this usage for trash folders:
> 
> If the file is on the same device as $home, use $home/.Trash. Otherwise
> check for an existing writable ".Trash" in the top dir of the filesystem
> of the file. If it exists, use (create if needed) $topdir/.Trash/$uid as
> the trash directory. If the .Trash directory doesn't exists, its up to
> the implementation to either create it if possible (I don't recommend
> implementations to do this for removable media, but detecting that case
> is a bit hard and the detection might differ between implementations),
> use $home/.Trash, or just not support trashing the file.
How would ownership work with .Trash/$uid instead of .Trash-$uid?
The user creating the .Trash directory would need to make it world-writable, right?

But I see the benefit over the .Trash-$uid solution indeed, for cases where
the sysadmin doesn't want to give write access to everyone in the filesystem root.
And at the same time, if we auto-create trash dirs that way, we don't have to
rely on the sysadmin, and this can still be useful (e.g. my /mnt/devel is owned
by "dfaure", so auto-creating a .Trash in there will mean much faster trashing
than moving to $home/.Trash, just because I forgot to create .Trash by hand).
OK for $topdir/.Trash/$uid/ then.

> This way each implementation will always use the same directory,
> sysadmins *can* set up trash directories for filesystems, and its still
> up to the implementations to choose how trashing is handled (unless you
> move media between implementations).
Well the whole point of this standardization is to be able to move media
(or open the same trash) between implementations. Why "unless"...?
As long as we find the .Trash directories created by the other implementations, 
we can see all trashed files, it doesn't matter if those files were rename()d
or actually copied there. I mean if you create a .Trash on removeable media
and I wouldn't, I'll still see it when opening the trash-can.

OK, it seems to me that we're converging here. I guess we need to write
a more formal spec than pointing people to this thread? :/

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