[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:  warner
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  soon
    Component:  code-    |    Version:  1.6.1
  frontend-cli           |   Keywords:  forward-compatibility docs tahoe-
   Resolution:           |  backup time
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by daira):

 Replying to [comment:18 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.

 It is possible for `ctime` to change but `mtime` not, when the file
 contents change. In particular, suppose there are two files `foo` and
 `bar` that have different contents but the same size and `mtime` (for
 example because they were created at the same time to within the `mtime`
 resolution). Then, `mv bar foo` will not change `foo`'s `mtime`, but will
 set its `ctime` to the current time. (Verified on Linux.)

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