Trash mechanism (url scheme)

[David Faure]

On Thursday 26 August 2004 15:44, David Faure wrote:
> The basic structure of the document would probably be like
> - Location of trash directories
> - Structure of the trash directories (info/ and files/ subdirs)
> - File ids (unique identifier used for the files in info/ and files/)
> - Contents of info files (original location \n date of deletion in ISO 8601 format)
> - Handling of deleted directories (nothing special :), but mention single info file)

Ah, and maybe a section on trash:/ URLs.

But I just realized that it needs a more general concept of fileids for it.
Both ~/.Trash/info/ and /mnt/devel/.Trash/501/info/ could contain
a "foo.txt" fileid. This is especially a risk with removeable media,
or with harddisk partitions being unmounted during trashing of a file
and remounted later.

So using the original filename ("foo.txt") as fileid is fine, but in URLs we 
need to specify which trash directory it comes from....
Since I don't want to expose the full path to the physical ".Trash" directory,
I'm not sure how to solve this. Actively renaming conflicting fileids when
discovering a new .Trash directory somewhere? [race condition again.....]
Adding yet another mapping layer, e.g. a global fileid which includes adds 
a number to conflicting fileids? Another kind of "additional mapping layer"
would be to assign ids to every physical ".Trash" directory (e.g. 0, 1, 2 etc.). 
Then the url scheme could simply be trash:/trashid/fileid, with the 
particularity that all such items are returned when listing trash:/ itself.
[I would even store the trashid on disk, e.g. in $trashdir/id to ensure persistence, 
since multiple processes could be handling trash urls].

All this is slightly unrelated to the "on-disk structure" spec, but since it seems
we'll all have the problem of how to uniquely identify a trashed file with
a single (user-readable if possible) string, it sounds like a good thing to solve
it in a common way as well.

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