Trash specification, version 0.1

[Alexander Larsson]

On Mon, 2004-08-30 at 14:09, Mikhail Ramendik wrote:
> 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?

All unix ones do. The only non-allowed characters in unix filenames are
'/' and zero.

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

It uses \n escaping.

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

How could it not be? Its the number of seconds since the epoch (00:00:00
UTC, January 1, 1970). Its what the posix time() function returns. It is
also how ctime, mtime and atime are stored in the structure returned
from stat(). So, its not like its an uncommon format for file times.

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

Sure.


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

Heh. Its just a script.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a war-weary ninja waffle chef with a passion for fast cars. She's a ditzy 
winged femme fatale who hides her beauty behind a pair of thick-framed 
spectacles. They fight crime!