[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