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

[tahoe-lafs]

#897: "tahoe backup" thinks "ctime" means "creation time"
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  zooko
         Type:  defect   |     Status:  assigned
     Priority:  major    |  Milestone:  soon
    Component:  code-    |    Version:  1.6.1
  frontend-cli           |   Keywords:  forward-compatibility docs tahoe-
   Resolution:           |  backup time
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 Replying to [comment:3 warner]:
 >
 > == using ctime/mtime in backupdb ==
 >
 > In particular, I'm not worried about trying to avoid re-uploading in the
 face of user-triggered changes to metadata that doesn't actually change
 file contents. If someone does a "chown" or "chmod" or "touch" on a bunch
 of files, I think they'll accept the fact that "tahoe backup" will
 subsequently do more work on those files than if they had not gone and run
 those commands.

 But why should we re-upload those files? The unix operating system is
 asserting, by giving us a changed {{{change time}}} and an unchanged
 {{{modify time}}}, that the file contents have not changed. If we are
 relying on the operating system about this sort of thing, for improved
 efficiency, then why not believe it about this and skip the re-upload?

 Obviously if the operating system asserts that the {{{creation time}}} has
 changed, then we should re-upload.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/897#comment:18>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage