Trash specification, version 0.1

[Dave Cridland]

On Mon Aug 30 13:09:18 2004, 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 POSIX ones, IIRC. I think NTFS does too, although I'd have to 
check. (I know you can't enter a filename with a newline in through 
the Windows GUI suite, but NTFS is [or can be] pretty well POSIX if 
you ask it nicely, so my guess would be it can.)


> 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?
> 
> 
> 
> > > 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 thought it was, in general. Although I'm not actually certain if 
ANSI C specifies it or not when I think about it.


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

As well:

1) It's useful to have the files human-readable. Obviously it's not 
advisable if this would add significant code-complexity.
2) RFC3339 is used in an increasing number of applications anyway, 
and being essentially a small subset of the most popular ISO8601 
timestamp format, is highly implemented anyway. If anyone writes 
their own parser/formatter, I'm at a loss to suggest why.
3) Depending on whether we choose to restrict to UTC, or allow, or 
enforce, localtime, we might need this anyway - epochs don't carry TZ 
offsets. [I believe these are useful. UTC is cool, but the ability to 
know what subjective time the file was deleted is also useful, as 
long as from that we can get to UTC.]
4) Trashing and untrashing of files does not need to be fast.

Dave.