Trash specification, version 0.1

[Lars Hallberg]

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.

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.

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!

If You own the file/subdirectory, a warning may be enuf with an offer to 
trash it anyway (this rase a standard question, ether *all* 
implementations *must* do this test so we now its OK to clean 
writeprotected stuff from trash, or the permisions have to be fixed - in 
witch case it have to be saved in metadata so it can be restored when 
recovering the file). If You don't own it, a warning and a cuestion 
whether to still trash the rest might be the right thing.

A trash implementation that silently trash stuff the user have taken the 
hard work to write protect is realy a bit evel on the user!

/LaH