If the files are equal and the conflict was created because the
timestamps were screwed the conflict is removed again. This only
works on the local repository so far.
Conflicts:
src/csync_propagate.c
The returned string of getenv() has an unknown size. You need to store
the result always in a char array with a certain size to make sure we
don't feed tainted data to the next function call.
When the folder is locked on windows, rmdir fails and the folmder is not
removed. But on the next sync, one should try to remove that folder again, and
not upload it to the server as we did before.
There was two problems:
1- The removed folder is still in the DB, so when csync_update read from
DB, for the remote, it still finds it. Fix that by storing an empty MD5
for directories that should have been deleted.
2- The folder is likely to be modified since its contents are gone.
Which means next sync will try to sync it back to the server.
Fix that by refreshing the mtime in the tree
Scenario:
We have A/B/C/file.txt
mv A/B/{C,C2}
start sync, and before sync ends
mv A A2
then as sync start and we try to merge, since it is no longer possible
to stat A/B/ which has been updated as C was moved, then the database
would not be synced
then start sync again and A/B/C2/file.txt is seen as new, and is
duplicated
By saving the database anyhow we work around that problem
It is important if there are operations such as delete, which operate on
the remote tree, and thet may also invalidate the id we got on the
localtree (for example, the parent directory of a removed file)
Do not do a stat before, it is unlikely that it succeed, and if it does
indeed show there is a file with the same name, the following mkdir ill
fail properly
(The only difference will be that EEXIST will be returned instead of
ENOTDIR
