Trash specification, version 0.1
Dave Cridland
dave at cridland.net
Mon Aug 30 13:20:56 EEST 2004
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.
More information about the xdg
mailing list