Trash specification, version 0.1

[Dave Cridland]

On Sun Aug 29 23:42:33 2004, Mikhail Ramendik wrote:
> The Trash specification, version 0.1, is available here:
> 
> http://www.ramendik.ru/docs/trashspec.html

Things I'd like to see:

A) One of:

1) Expansion space in the info files. So extra lines in the info file 
MUST be ignored unless defined by a future specification.

2) I'm a little concerned by just how simple the info file format is. 
Although a more complex file format wouldn't help the first two 
lines, I'm more concerned by what might happen if we need to extend 
this format. (No, I can't think of a reason why we'd need to 
*yet*...) Given we have a standardish file format already, what's the 
problem with using  something similar to the Desktop file format? 
Agreed, there'd be a slight performance hit when reading or writing 
the info files, but it gains us extensibility easily.

B) Are we sure that UTC times are the best for this? I'm thinking, in 
particular, that a file deleted at 1:30 in the morning might be 
considered as more prone to accident than a file deleted at 14:00 - 
in other words, the local time might be significant.

C) What gets written first? The info file or the actual trash file? 
(I think the trash file, since that may simply be renamed into 
position. Then the info file, so that if we run out of disk space, we 
can gracefully continue. Some operating systems apparently flag a 
device full error as a fatal error while deleting files. This is 
embarrassingly stupid.)

D) Rather than ISO8601, can we use RFC3339 instead? It's the same 
thing, but the specification is simpler and cut-down. Moreover, I 
believe that ISO8601 isn't a freely available specification, is quite 
large, and thus there's a greater chance of misinterpretation. (Not 
that I think anyone is likely to write a date in there as 
"2004272T111027.22467Z" - I believe a valid ISO date time, but it's 
worth specifying that explicitly.)

E) What happens when you delete a file /home/me/foo, then create a 
new one, then undelete the first?

F) Some suggestions for deriving a filename which is unlikely, or 
impossible, to clash would be nice. (Or at least some suggestion that 
this is needed.)

G) I'd like an RFC-style Security Considerations section.

Aside from those issues, one stylistic issue which I've mentioned to 
Mikhail directly, and he suggested may need discussion on the list:

"$trash" and "$topdir" should be replaced, I think, with "<trash>" 
and "<topdir>", to make it clear that they're not environment 
variables.

I should make it aboslutely clear that I've not been following the 
discussion between David and Alexander at all since Mikhail said he'd 
write the spec. I do think this is an excellent way of coming up with 
a solid specification, and Mikhail seems to be doing an excellent job 
of it.

Dave.