Trash specification, version 0.1

[Mikhail Ramendik]

Alexander Larsson wrote:

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

Does any filesystem allow this?

If so, we need to provide for "escaping". But then, other files (like
*.desktop) probably had to deal with this somehow. What is the solution
there?

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

Agreed. This will be in 0.3.

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

But is an epoch number portable across operating systems and
architectures? 

I'd prefer this spec to be implementable under any OS at all, if the
developers so choose. 

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

Agreed. This will be in 0.3.

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

I'll mention this, along with random generation, in "Implementation
notes".

Yours, Mikhail Ramendik

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

(offtopic: what do you generate this with? <g>)