From: Daira Hopwood <daira@jacaranda.org>
Date: Mon, 28 Dec 2015 19:18:28 +0000 (+0000)
Subject: Fix a subtle bug in the overwrite algorithm.
X-Git-Url: https://git.rkrishnan.org/vdrive/%22news.html/COPYING.GPL?a=commitdiff_plain;h=616eb27b80756b473711c8ebfcff4614322bad41;p=tahoe-lafs%2Ftahoe-lafs.git

Fix a subtle bug in the overwrite algorithm.
See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2640#comment:3 .

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
---

diff --git a/docs/proposed/magic-folder/remote-to-local-sync.rst b/docs/proposed/magic-folder/remote-to-local-sync.rst
index b41de7bf..8854913c 100644
--- a/docs/proposed/magic-folder/remote-to-local-sync.rst
+++ b/docs/proposed/magic-folder/remote-to-local-sync.rst
@@ -375,7 +375,12 @@ this procedure for an overwrite in response to a remote change:
    conflict. (This takes as input the ``last_downloaded_uri``
    field from the directory entry of the changed ``foo``.)
 3. Set the ``mtime`` of the replacement file to be *T* seconds
-   before the current local time.
+   before the current local time. Stat the replacement file
+   to obtain its ``mtime`` and ``ctime`` as stored in the local
+   filesystem, and update the file's last-seen statinfo in
+   the magic folder db with this information. (Note that the
+   retrieved ``mtime`` may differ from the one that was set due
+   to rounding.)
 4. Perform a ''file replacement'' operation (explained below)
    with backup filename ``foo.backup``, replaced file ``foo``,
    and replacement file ``.foo.tmp``. If any step of this
@@ -409,10 +414,10 @@ set in step 3. The move operation in step 4b will cause a
 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
+has finished, at which point the last-seen statinfo 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.)
 
 .. _`magic folder db`: filesystem_integration.rst#local-scanning-and-database
@@ -786,7 +791,7 @@ may be absent). Then the algorithm is:
 * 2b. Read the following information for the path ``foo`` from the
   local magic folder db:
 
-  * the *last-uploaded statinfo*, if any (this is the size in
+  * the *last-seen statinfo*, if any (this is the size in
     bytes, ``mtime``, and ``ctime`` stored in the ``local_files``
     table when the file was last uploaded);
   * the ``last_uploaded_uri`` field of the ``local_files`` table
@@ -796,7 +801,7 @@ may be absent). Then the algorithm is:
 * 2c. If any of the following are true, then classify as a conflict:
 
   * i. there are pending notifications of changes to ``foo``;
-  * ii. the last-uploaded statinfo is either absent (i.e. there is
+  * ii. the last-seen statinfo is either absent (i.e. there is
     no entry in the database for this path), or different from the
     current statinfo;
   * iii. either ``last_downloaded_uri`` or ``last_uploaded_uri``