[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2640: upload/download loop

Tahoe-LAFS trac at tahoe-lafs.org
Tue Dec 15 16:30:21 UTC 2015


#2640: upload/download loop
-------------------------------------+-------------------------------------
     Reporter:  meejah               |      Owner:  daira
         Type:  defect               |     Status:  new
     Priority:  normal               |  Milestone:  undecided
    Component:  code-frontend-       |    Version:  1.10.2
  magic-folder                       |   Keywords:  magic-folder
   Resolution:                       |  integration-test
Launchpad Bug:                       |
-------------------------------------+-------------------------------------

Comment (by daira):

 Ah ok. That's not supposed to happen because we're supposed to
 [https://github.com/tahoe-lafs/tahoe-lafs/blob/2438.magic-folder-
 stable.5/docs/proposed/magic-folder/remote-to-local-sync.rst
 #writedownload-collisions set the `mtime` of the downloaded temporary
 file] and record the same `mtime` in the database:

 > Note that, if there is no conflict, the entry for `foo` recorded in the
 magic folder db will reflect the `mtime` set in step 3 [of the overwrite
 algorithm]. The move operation in step 4b will cause a `MOVED_FROM` event
 for `foo`, and the link operation in step 4c will cause an `IN_CREATE`
 event for `foo`. However, these events will not trigger an upload, because
 they are guaranteed to be processed only after the file replacement has
 finished, at which point the metadata recorded in the database entry will
 exactly match the metadata for the file's inode on disk. (The two hard
 links — `foo` and, while it still exists, `.foo.tmp` — share the same
 inode and therefore the same metadata.)

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


More information about the tahoe-lafs-trac-stream mailing list