[tahoe-dev] [tahoe-lafs] #897: "tahoe backup" thinks "ctime" means "creation time"

[tahoe-lafs]

#897: "tahoe backup" thinks "ctime" means "creation time"
-----------------------------------------------------+----------------------
 Reporter:  zooko                                    |           Owner:  warner   
     Type:  defect                                   |          Status:  new      
 Priority:  major                                    |       Milestone:  undecided
Component:  unknown                                  |         Version:  1.5.0    
 Keywords:  forward-compatibility docs tahoe-backup  |   Launchpad_bug:           
-----------------------------------------------------+----------------------

Comment(by warner):

 The only argument for {{{st_platform}}} is to give readers (including
 dirreadcap holders) a hedge against failures in our current understanding
 of what these fields mean (well, our+python's understanding). I'm +0 on it
 now.. I could be talked out of including it.

 I suspect that our inclusion of st_ino and st_dev and the other fields
 will reveal much information about the value of st_platform anyways, since
 I imagine that windows filesystems use these fields in very different
 ways. An enthusiastic reader who is trying to un-"fix" our+python's
 attempt at being helpful might be able to recognize these characteristic
 st_ino/st_dev values and improve the accuracy of their unwinding without
 being told explicitly what st_platform is. On the other hand, st_platform
 may not be enough information to do this hypothetical job well, and that
 future reader may complain to our ghosts that we should have included even
 more information.

 So I'm ok with not including st_platform.

 > I think they are the same.

 I suspect they are the same too, but I'm afraid of committing the same
 mistake that Python did, especially when OS-X is the only documentation
 that I've seen personally, and nobody that I know has even seen the
 hypothetical ZFS docs (and ZFS is losing ground now that Apple abandoned
 it). Again, I'm willing to go this way, but I'm going to be awfully
 embarrassed if our attempt to fix python's semantics proves (years from
 now) to be adding yet another layer of brokenness.

 > Also I think posix-change-time should be metadata-change-time,

 I'm also willing to go along with this one, but I'm even more hesitant.
 First, I think the casual reader who sees "metadata-change-time" will
 incorrectly assume that it is referring to the Tahoe metadata in which
 this key is embedded, rather than the original disk filesystem from which
 the file was copied. Second, do we have examples of non-POSIX systems
 which provide this "ctime" that behave exactly like POSIX ones? We'd be
 making a bolder claim by going with "metadata-change-time".. there are
 surely some pieces of metadata that might be changed without updating this
 timestamp.. if some other system uses a different set of metadata than our
 POSIX systems, would we ignore the differences and represent both at
 "metadata-change-time"? Or add a "non-POSIX-metadata-change-time" ?

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