[tahoe-dev] [tahoe-lafs] #628: "mtime" and "ctime": I don't think that word means what you think it means.

[Shawn Willden]

On Wednesday 25 February 2009 09:02:22 am tahoe-lafs wrote:
>  Also, nobody should do this until Brian comments on this ticket about my
>  proposal that we stop reading the ctime from the local filesystem, or that
>  if we do read the ctime from the local filesystem, that we then switch on
>  platform type, and if Windows then put the value we read into a metadata
>  element named "create time", else put the value we read into a metadata
>  element named "change time" ("change time" is, I think, the official
>  expansion of the unix abbreviation "ctime").  Also that we store the
>  "mtime" in an element named "modify time".

This is a good point.  I'll adopt that for my backup system's metadata 
storage.  As soon as I get some time to hack on it, that is.  It doesn't 
actually affect change detection because I assume that any metadata change 
(except atime) is a possible sign of content change and hash the file.  That 
may be overly conservative, but I figure extra hashing is much cheaper than 
missing a backup.

BTW, I notice that cygwin addresses this point by having 'stat' return the 
mtime value for both mtime and ctime, ignoring the Windows create time 
entirely.  Not a perfect solution, but one that preserves semantics that are 
close to what Unix tools expect (which is that ctime >= mtime).

IMO, this is a bug in the Python os.stat and os.lstat implementations.  They 
should not return values with radically different meanings in the same field.

	Shawn.