Trash specification, version 0.1

[Lars Hallberg]

Alexander Larsson wrote:

>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 panel on the desktop I would count as the desktop. Trashing mening 
different things in diferent context sounds strange, but if we look at 
it from a more user perspektiv and not so tecnical. The desktop is an 
metafor for my cumputer, the filebrowser window is a metafor for what 
I'm curintly browsing. So, trashing something om my desktop shuld end up 
on my desktop, trashing somthing in my filebrowser window may end up 
where I browse, kind of make sens.

Argubly, You can put stuf on the desktop that are a metafore for 
someplace else, like an ikon reprecenting  a netmounted directory. But I 
don't realy feel the natural asociation with the trashcan to be some 
virtual colektions of trashcans oround the net and different removeble 
device/media.

If the 'recover trashed' file funktion help me recover stuff all over 
the net amd media, OK, but the most comen use I guess is to ask, what 
have I trashed in this derectory? You tend to now from where You miss 
stuff when You miss stuff.

>>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,
>
Trashing to another partision will free space in it's self, posably 
during the proces.

>unmount the volume
>  
>
That is true!

>or use the directory you removed stuff from for anything else until the
>trashing is done.
>  
>
Why? Moving stuf to .trash-in-progress wold make the directory look like 
the proces is done from the start. This is only true if the 
browserwindow is 'tied' up by some modal design.

>>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.
>  
>
Yes, it's less slow, and *much* more important.

Sorry to all on the list, my last mail had the wrong from and is stuck 
in moderation :-/

And another story, I see now that .Trash-$uid is only suposed to be 
created if ther is no .Trash/. Thats OK I guess. Can't think of a case 
wher I want to forbid trashing while the users have the right to create 
.Trash-$uid on the top-dir. Makes litle sens.

But the "user A trashing file foo prevent user B from freeing up space 
fore it, even if user B originaly had the right to delete file foo" 
problem, is that handeled?

If it's trashing to the homedir, it's OK, becouse sysadm can handle that 
with quota! But on shared partisions... It's a real problem.

/LaH