Trash specification, version 0.1

[Alexander Larsson]

On Mon, 2004-08-30 at 12:20, Dave Cridland wrote:
> 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.

Makes sense.

> 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.

An interesting issue is filenames with newlines in them.

> 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.)

Not only does does one has to be written first. We need to protect from
races by doing an atomic create with the O_EXCL on the file in info
first, before writing anything in files.

> 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.)

Even rfc3339 is way to complicated than the YYYYMMMDD:HHMM or whatever
that was initially mentioned. All this complication is way unnecessary,
since this is all machine parsed anyway. I see little or no reason for
not just using an epoch number for the time, anything else will just
result in thousands of lines of wasted parsing code to convert the
string date to the internal representation which is likely an epoch. 

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

Undelete fails, in implementation-defined ways. (I.E. this is outside
the scope of the spec).

> 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.)

Yes. What was mentioned in the thread was to first use the real
filename, then use whatever duplicating system used already on the
desktop system in question (such as adding " (copy $n)", or ".$n" to the
string.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an obese small-town barbarian from a doomed world. She's a high-kicking 
red-headed doctor in the wrong place at the wrong time. They fight crime!