Trash specification, version 0.1

[Dave Cridland]

On Mon Aug 30 11:40:13 2004, Mikhail Ramendik wrote:
> > 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.
> 
> Local times might be quite inconvenient on globally shared 
> resources.
> (I.e. an office NFS available over VPN to overseas employees).
> 
> It's usually easy to get the local time from UTC, and not always 
> easy to
> get UTC from a local time (if the local time on the requesting 
> system is
> different).
> 
> So I'm for UTC here. 
> 
I'd disagree, primarily because I'm reversing your argument.

It's always possible to take a given, fully qualified, local 
timestamp and get to UTC. To go to the reverse isn't possible - you 
can find the current user's current local time, but you can't know 
what timezone they were operating in when they deleted the file.

Let's suppose that I normally work in the UK (as I do), but supposing 
I went to the states for a weekend, and deleted some file or other 
while there at 3am.

The system can know what moment I deleted the file, but it doesn't 
know I deleted it in the middle of the night - instead, it thinks I 
deleted it at 11am - a time it might decide I'm less likely to make a 
mistake.

Equally, a system might automatically purge all files deleted over 
one full working day before - that really needs to know when the file 
was deleted in subjective time.

It doesn't lose anything, but does gain.


> > 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.)
> 
> I would support writing the info file first. An "orphaned" info 
> file is
> just a nuisance; an "orphaned" trash file is a piece of lost
> information.
> 
> 
Again, I'd say this is the other way around. Whichever, an 
implementation obviously can't erase the original and then write the 
trash file. Alexander's comments suggest that it probably doesn't, in 
fact, matter - you have to open/create both files before filling in 
the content of the info file anyway. My gut feeling is that you 
generally want to handle the trashed file itself first, then add the 
metadata, which by definition is less critical to lose.

Dave.