This also allow to reduce duplicate code in csync_commit, and ease the
error reporting of csync_commit
csync_commit is supposed to be done after the previous sync, it is
better to open the statedb before the sync
- use proper casts
- use aproproate types
- offer to build with -Werror
- make printf attribute hinting gnu format style
- remove unused helper methods
- begin to use inttyes.h macros where suitable
- move var declarations to the beginning of the method
- properly use _FILE_OFFSET_BITS
- silence variables unused depending on the define
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.
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.
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.
