Clarifications and TODO.

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 0fc8288e1887871297f7701f9c9c85079feb974e..d58e1f4e8297535403bee11bfed393445edbf3a9 100644 (file)
--- a/docs/proposed/magic-folder/remote-to-local-sync.rst
+++ b/docs/proposed/magic-folder/remote-to-local-sync.rst
@@ -397,12 +397,11 @@ operations performed by the Magic Folder client and the other process.
 (Note that atomic operations on a directory are totally ordered.)
 
 * Interleaving 1a: the other process' rename precedes our rename in
-  step b, and we get an ``IN_MOVED_TO`` event for its rename before
-  we do ours. Then we reclassify as a conflict; its changes end up
-  at ``foo`` and ours end up at ``foo.conflicted``. This avoids
-  data loss.
+  step b, and we get an ``IN_MOVED_TO`` event for its rename by step 2.
+  Then we reclassify as a conflict; its changes end up at ``foo``
+  and ours end up at ``foo.conflicted``. This avoids data loss.
 * Interleaving 1b: its rename precedes ours in step b, and we do
-  not get an ``IN_MOVED_TO`` event for its rename before ours. Its
+  not get an ``IN_MOVED_TO`` event for its rename by step 2. Its
   changes end up at ``foo.old`` and ours end up at ``foo``. This
   avoids data loss.
 * Interleaving 2: its rename happens between our rename in step b,
@@ -428,6 +427,8 @@ between steps b and c. In this case the open will fail because ``foo``
 does not exist. Nevertheless, no data will be lost. (Probably, the user
 will be able to retry the operation.)
 
+On Windows, [TODO interleavings of rename vs ReplaceFileW].
+
 Above we have considered only interleavings with a single other process,
 and only the most common possibilities for the other process' interaction
 with the file. If multiple other processes are involved, or if a process