Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1

Ted Lemon <mellon@fugue.com> Mon, 07 December 2015 03:40 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: storagesync@ietfa.amsl.com
Delivered-To: storagesync@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840AF1B2D26 for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 19:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbNzHm8KZ2Rf for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 19:40:25 -0800 (PST)
Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9B1B2D25 for <storagesync@ietf.org>; Sun, 6 Dec 2015 19:40:24 -0800 (PST)
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494596157930.7679847076069564"
From: Ted Lemon <mellon@fugue.com>
To: fsong@bjtu.edu.cn
In-Reply-To: <2015120711170621874681@bjtu.edu.cn>
References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <CAO_YpraJsDKbOXD9MdxHqeAYTMoiZFyViHX+P2PtD=9hpRz9MQ@mail.gmail.com> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <CAO_YpramyzAZ8hS6aphmBNw2FiKTpesb9uW7uGHtjRH_YkPAJg@mail.gmail.com> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn>
Date: Mon, 07 Dec 2015 03:40:15 +0000
Message-Id: <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/aL-X21CpSX7K2XbHJXXYH5FQwHA>
Cc: storagesync@ietf.org
Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
X-BeenThere: storagesync@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services <storagesync.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storagesync>, <mailto:storagesync-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/storagesync/>
List-Post: <mailto:storagesync@ietf.org>
List-Help: <mailto:storagesync-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storagesync>, <mailto:storagesync-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 03:40:26 -0000

Sunday, Dec 6, 2015 10:17 PM Fei Song wrote:
> Can we just treat the requests sent by peer B and peer C based on their timestamps (arriving at the server).
> If the file must be kept as the same version, different modification reports can be generated independently with FCFS mode.
> If this can not be finished automatically, a human intervention will be needed.

No, this doesn't work even if you don't care about wiping out changes.   Think about this sequence:

0: File F is at version 0
1: Client A syncs to server
2: Client B syncs to server
3: File f changed on Client A -> Version 0.A
4: File f changed on Client B -> Version 0.B
5: Client B syncs to server, updating file F to version 0.B, modified time = 4
6: Client A syncs to server: what happens?
   a: File updated to version 0.A, modified time=3
   b: Server overwrites version 0.A with version 0.B, changes in 0.A lost
   c: Conflict resolution combines versions 0.A and 0.B, producing version 1, mod time=6

I think C is the only right answer.   We want conflict resolution to be automatic whenever possible, but we do want to do conflict resolution, and not just wipe out changes, because those changes may contain real work that the user on client A did.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com