ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-01-06 13:08:42 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix an oversight in the design doc.

Browse Source
This commit is contained in:
Daira Hopwood 2015-09-24 20:44:09 +02:00
parent 4b037308f0
commit f0b38b5c1d
1 changed files with 14 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/proposed/magic-folder/remote-to-local-sync.rst
View File

@ -395,14 +395,17 @@ and Windows. On Unix, it can be implemented as follows:
suppressing errors. suppressing errors.
Note that, if there is no conflict, the entry for ``foo`` Note that, if there is no conflict, the entry for ``foo``
recorded in the `magic folder db`_ will reflect the ``mtime`` recorded in the `magic folder db`_ will reflect the ``mtime``
set in step 3. The link operation in step 4c will cause an set in step 3. The move operation in step 4b will cause a
``IN_CREATE`` event for ``foo``, but this will not trigger an ``MOVED_FROM`` event for ``foo``, and the link operation in
upload, because the metadata recorded in the database entry step 4c will cause an ``IN_CREATE`` event for ``foo``.
will exactly match the metadata for the file's inode on disk. However, these events will not trigger an upload, because they
(The two hard links — ``foo`` and, while it still exists, are guaranteed to be processed only after the file replacement
``.foo.tmp`` — share the same inode and therefore the same has finished, at which point the metadata recorded in the
metadata.) 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 .. _`magic folder db`: filesystem_integration.rst#local-scanning-and-database
@ -411,9 +414,9 @@ call to the `ReplaceFileW`_ API (with the
``REPLACEFILE_IGNORE_MERGE_ERRORS`` flag). ``REPLACEFILE_IGNORE_MERGE_ERRORS`` flag).
Similar to the Unix case, the `ReplaceFileW`_ operation will Similar to the Unix case, the `ReplaceFileW`_ operation will
cause a change notification for ``foo``. The replaced ``foo`` cause one or more change notifications for ``foo``. The replaced
has the same ``mtime`` as the replacement file, and so this ``foo`` has the same ``mtime`` as the replacement file, and so any
notification will not trigger an unwanted upload. such notification(s) will not trigger an unwanted upload.
.. _`ReplaceFileW`: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365512%28v=vs.85%29.aspx .. _`ReplaceFileW`: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365512%28v=vs.85%29.aspx