Trash specification, version 0.1

[Alexander Larsson]

On Fri, 2004-09-03 at 10:34 +0200, Lars Hallberg wrote:
> Alexander Larsson wrote:
> 
> >On Fri, 2004-09-03 at 09:01 +0200, Lars Hallberg wrote:
> >
> >  
> >
> >>One implementation detail, I do expect, if I drag files to the trachcan, 
> >>they are trached in my ~/.trash, regardless of what partision or media 
> >>they on from the start!
> >>    
> >>
> >
> >Why do you expect this? That means trashing will become a very slow
> >operation.
> >  
> >
> Whell, if I drag something to my desctop from posably not always mounted 
> partision or a removable device/media, i expect it to end up on my 
> desctop even after the mount/media is removed! Trashing from the actual 
> 'alien' directory with a menu/rightclickmenu/keybinding is another 
> story. But this might be an implementation detail, but IMHO important 
> enuf for a recomendation.

You consider dragging a file to the trashcan on the desktop, as opposed
to one on e.g. the panel or using the "move to trash" menu entry a
different kind of operation? I must say i've never heard anyone do this
distinction before, and I don't personally think it makes sense to have
such a distinction.

> The ui does not necasarly have to be slower, the actual traching might 
> be backgrounded with a spinner, prograssbar or whatever in the status 
> bar. This obvius complicate implementation with respect to closing the 
> app, logout and shutdown handling etc. A trash progresbox thats non 
> modal (maybe its own process) might be simpler, it lives until done even 
> if the app is closed! Stuff like first move it to .trash_in_progress, 
> then copy, then delety might be more robust. If the itermeadiat location 
> is pointed out of a standard metadata in ~/(whatewer)Trash, different 
> implementation can possably finish etchothers interupted job, improving 
> robustness even more.

It *does* mean its slower. You can't free the space, unmount the volume
or use the directory you removed stuff from for anything else until the
trashing is done.

> Another problem that might slow down trashing, but not that much is 
> trashing directorys. I beleve a trash implementasion have to check if 
> the user have the right to delete all files in the directory.
> 
> Conseptaly, if You don't have the right to deleta a file, You should not 
> have the right to trash it - even if You have the right to rename the 
> directory it's in!

Yes. This is a bit problematic. Especially if you have right to rename a
directory, but it contains a file owned by someone else you can't ever
remove (even with chmod). However, even if you look for issues like
this, its only metadata checks. Its never as slow as copying all the
files on a floppy or flash-memory card to the HD. That can take several
minutes.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an old-fashioned gay Green Beret with acid for blood. She's a virginal 
psychic vampire from out of town. They fight crime!