Trash specification, version 0.1
lah at micropp.se
Fri Sep 3 11:34:29 EEST 2004
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
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!
More information about the xdg