[tahoe-lafs-trac-stream] [Tahoe-LAFS] #601: add 'tahoe sync' command, for bidirectional synchronization

[Tahoe-LAFS]

#601: add 'tahoe sync' command, for bidirectional synchronization
-----------------------------------+-----------------------
     Reporter:  warner             |      Owner:
         Type:  enhancement        |     Status:  closed
     Priority:  major              |  Milestone:  undecided
    Component:  code-frontend-cli  |    Version:  1.2.0
   Resolution:  was already fixed  |   Keywords:  usability
Launchpad Bug:                     |
-----------------------------------+-----------------------
Changes (by exarkun):

 * status:  new => closed
 * resolution:   => was already fixed


Old description:

> Peter pointed out that it would be really useful to have a tool that
> would perform a bidirectional sync between a local directory and a tahoe
> directory. You could establish a relationship between the two, then
> periodically sync them later. Multiple machines could sync to the same
> online target. The overall use case is to let a laptop user edit their
> files while they're on a plane, then have them uploaded automatically
> once they get online again, then be able to edit them from a desktop
> machine later.
>
> Of course, this is really a version-control problem, and the general case
> (with multiple uncoordinated committers) is seriously non-trivial. But,
> the single-user infrequent-collision case is easier.
>
> The basic idea would be that the host would have a table, with one row
> per local file, and each row would contain some sort of version
> identifier for the local file's contents, and a second identifier for the
> remote file contents, both as of the last sync. The Tahoe-side remote
> identifier could just be a readcap. The local identifier could be a full
> hash of the file, or it could be a timestamp+filesize
> optimization/abbreviation.
>
> When the sync is performed, it checks the local file to see if it still
> matches the last-known-identifier, and it checks the remote file to see
> if it matches the last-known-identifier. If both are the same, no work
> needs to be done. If exactly one has changed, then that side is
> considered newer, and it is copied to the other side. If both have
> changed, we have a conflict, and the user is required to look at the two
> versions and make a decision. Once the file is processed, the table is
> updated with the new (identical) version identifiers.
>
> A suitable UI for the conflict indication-and-resolution phase is
> necessary.

New description:

 Peter pointed out that it would be really useful to have a tool that would
 perform a bidirectional sync between a local directory and a tahoe
 directory. You could establish a relationship between the two, then
 periodically sync them later. Multiple machines could sync to the same
 online target. The overall use case is to let a laptop user edit their
 files while they're on a plane, then have them uploaded automatically once
 they get online again, then be able to edit them from a desktop machine
 later.

 Of course, this is really a version-control problem, and the general case
 (with multiple uncoordinated committers) is seriously non-trivial. But,
 the single-user infrequent-collision case is easier.

 The basic idea would be that the host would have a table, with one row per
 local file, and each row would contain some sort of version identifier for
 the local file's contents, and a second identifier for the remote file
 contents, both as of the last sync. The Tahoe-side remote identifier could
 just be a readcap. The local identifier could be a full hash of the file,
 or it could be a timestamp+filesize optimization/abbreviation.

 When the sync is performed, it checks the local file to see if it still
 matches the last-known-identifier, and it checks the remote file to see if
 it matches the last-known-identifier. If both are the same, no work needs
 to be done. If exactly one has changed, then that side is considered
 newer, and it is copied to the other side. If both have changed, we have a
 conflict, and the user is required to look at the two versions and make a
 decision. Once the file is processed, the table is updated with the new
 (identical) version identifiers.

 A suitable UI for the conflict indication-and-resolution phase is
 necessary.

--

Comment:

 This seems like what is now "magic folders".  The only difference is that
 "magic folders" does the sync for you based on OS file change notification
 (or passage of time if notification fails).

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