Trash specification, version 0.1

[David Faure]

On Monday 30 August 2004 22:18, C. Gatzemeier wrote:
> [/Trash/A/B/C/datafile]
> - storage directly usable even witout extra trash tools (CLI)
The proposed .Trash-$uid/files/foo.txt is also usable from the CLI.
Either manually (you know where you want to move the file to),
or with a small script that reads it from the info file.
It would even be simpler to write than "removing files with a deletion date
from the directory before moving it back", which your solution would need.
For a given fileid, it would simply have to 
1) read orig path from info/$fileid
2) mv files/$fileid $origpath.
In any case I suspect that if this spec does become standard, extra
command-line tools will be developed, since it is rather easy to do.
Manual command-line usage will be mostly for last-resort recovery.

> - trashing operation purely on filesystem meta-data
Hacking information into a filename isn't really "pure" IMHO.
What if the user named a file foo.txt[2004-06-04T14:54:00] in the first place?
Then the code is going to think that's just metadata and strip it out...

> - no known or hidden permission problems
Arguable - it all depends on whether the trash is considered a "private"
thing or a "possibly shared, when the initial file was shared" thing.
I still think the latter is a dangerous road, and the trash is basically a private
thing, so I don't see a problem with .Trash-$uid.

> - same format regardless of $topdir location
Now that Alex suggested .Trash-$uid instead of .Trash/$uid/, I was about
to suggest that we use .Trash-$uid everywhere, including in $HOME.
This is more consistent - but well, that's about the only gain.

I think you're missing the complexity introduced by mixing items from 
different dates of deletion into the same directories. From an implementation
point of view, that approach makes things quite difficult, requiring full-depth
searches, guessing things from filenames, moving out and back in after
undeletion of the rest, etc.

It's good to discuss every option but I hope we can move forward to a 
common solution at some point. The whole idea of a standard specification
falls apart if everyone wants a different solution...

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