Fixes: https://github.com/owncloud/mirall/issues/595
Some corruptions do not happen when the database is opened, but only on
some querries.
In that case, recreates the database if querries such as DROP or
CREATE fails.
Don't take in account which file is newer, the conflict file will always
be on the locale side.
This patch also consider that INSTRUCTION_NEW and INSTRUCTION_EVAL means
the same.
Consider this case when one creates a file with an invalid filename (for
the server) in a directory in the local side.
say: foo/bar/%invalid%.txt
The following would happen:
- in the update for the local parent folder foo/bar/, the md5 is 0
because the mtime has changed
- During the reconcile, we try to send %invalid%, but there will be an
error and nothing will be changed on the server, the etags stay the
same
- We do not do any PROPFIND at the end so we do not fetch the etag
anymore. The md5 is still 0 and will be saved like that in the DB
- Next run, since the etags have not changed on the server, we read
from the DB. But a md5 of 0 in the DB means the folder was removed on
the server. That would remove the local folder (BAD!)
So we load the md5 from the db even if the local mtime change.
That means we need to compare the mtime in the local case rather than
the md5 to see if something has changed.
csync would not update the etag (md5) for directoru in the database if
the etag has changed, but none of the files within that directory
actually changed
Consider this case when one creates a file with an invalid filename (for
the server) in a directory in the local side.
say: foo/bar/%invalid%.txt
The following would happen:
- in the update for the local parent folder foo/bar/, the md5 is 0
because the mtime has changed
- During the reconcile, we try to send %invalid%, but there will be an
error and nothing will be changed on the server, the etags stay the
same
- We do not do any PROPFIND at the end so we do not fetch the etag
anymore. The md5 is still 0 and will be saved like that in the DB
- Next run, since the etags have not changed on the server, we read
from the DB. But a md5 of 0 in the DB means the folder was removed on
the server. That would remove the local folder (BAD!)
So we load the md5 from the db even if the local mtime change.
That means we need to compare the mtime in the local case rather than
the md5 to see if something has changed.
