Bug owncloud/mirall#779 reports about continous upload of files
even though nothing has changed. Logfiles show the fact that the
inode on windows is not reliable for this. Disabled as a result
to fix bug #779.
- 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
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.
