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

[tahoe-lafs]

#628: "mtime" and "ctime": I don't think that word means what you think it means.
---------------------------+------------------------------------------------
 Reporter:  zooko          |           Owner:           
     Type:  defect         |          Status:  new      
 Priority:  major          |       Milestone:  undecided
Component:  code-dirnodes  |         Version:  1.2.0    
 Keywords:                 |   Launchpad_bug:           
---------------------------+------------------------------------------------

Comment(by zooko):

 Thanks, Terrell.  Add to that list:

 5) Windows NTFS creation time - named "ctime" -- when the file was
 originally created (Windows apps usually try to preserve this timestamp
 when doing transfers, backups/restores, etc.)

 6) Mac HFS+ creation time - named "crtime" -- when the filesystem object
 was originally created (so I think this is supposed to be touched when an
 object in the local filesystem is created, instead of copied from some
 other source e.g. during a restore, but I'm not sure.)

 7) ZFS creation time - named "crtime" -- not sure what this means


 Hm, so if I {{{tahoe cp}}} a file from Windows to Tahoe, then {{{tahoe
 cp}}} it from Tahoe to Linux, then change its owner (touching ctime), then
 {{{tahoe cp}}} it back to Tahoe and then back to Windows, then it will
 have its Windows "creation time" overwritten with the time that I changed
 the ownership?  From the perspective of Windows, this is clearly wrong.  I
 think the source of the problem is that the the Windows API use the word
 "ctime" to mean file creation time (hm...  I wonder if it was because they
 thought that's what the unix "ctime" had been intended for...) and the
 implementors of the Python API accidentally put both Unix "ctime" and
 Windows "ctime" into the same slot in the stat call:

 http://docs.python.org/library/os.html#os.stat

 (NTFS ''also'' stores the POSIX "change time" ctime, but I don't think
 Python offers a way to access it.  Because who cares about the POSIX
 "change time"?)

 I think we should make a general rule that we never look at the
 {{{st_ctime}}} slot of the stat struct unless we then switch on platform
 type, or perhaps the even more general rule that we never look at the
 {{{st_ctime}}} slot of the stat struct.  ;-)

 references:

 http://en.wikipedia.org/wiki/Mac_times
 http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/628#comment:3>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid