Fix some possible "Precondition Failed" bug

The problem was if there was a false conflict: the file has been touched
both on the server and the client.
 - etag has changed on the server
 - mtime has changed on the server and the client and is the same
 - and file size is the same on both the server and the client

This may also happen if the file is uploaded on the server, but the client
looses connection (or crashes) before it get notified of the etag.

In both tree, the instruction is EVAL, but we reduce it to a NONE because
we detected that the conflict is 'false'.  Still, we need to update the db
with the new etag.  (_should_update_db)
The problem was that we would set the flag on the wrong tree.
This was not a problem when the file was NEW on both side since  we checked
for null etag and used the other one then.
This commit is contained in:
Olivier Goffart 2014-06-03 11:14:07 +02:00
Родитель 746c15b4aa
Коммит 13f9970257
1 изменённых файлов: 6 добавлений и 2 удалений

Просмотреть файл

@ -249,8 +249,12 @@ static int _csync_merge_algorithm_visitor(void *obj, void *data) {
cur->instruction = CSYNC_INSTRUCTION_NONE; cur->instruction = CSYNC_INSTRUCTION_NONE;
other->instruction = CSYNC_INSTRUCTION_NONE; other->instruction = CSYNC_INSTRUCTION_NONE;
if( !cur->etag && other->etag ) cur->etag = c_strdup(other->etag); /* update DB with new etag from remote */
cur->should_update_etag = true; /* update DB */ if (ctx->current == LOCAL_REPLICA) {
other->should_update_etag = true;
} else {
cur->should_update_etag = true;
}
} else if(ctx->current == REMOTE_REPLICA) { } else if(ctx->current == REMOTE_REPLICA) {
cur->instruction = CSYNC_INSTRUCTION_CONFLICT; cur->instruction = CSYNC_INSTRUCTION_CONFLICT;
other->instruction = CSYNC_INSTRUCTION_NONE; other->instruction = CSYNC_INSTRUCTION_NONE;