If the Folder::Map object is kept locally in the wizard, changes to
the map are not reflected there, as they happen when signing out.
This fixes bug #1875
Direcotries are removed at the end, and we don't want to update
parent directory etag before the delete is performed, or the next
sync may read from db and think the files are not removed.
Issue #1845
When we detect a precondition failed, it is possible that it is
because the etag in the database is wrong. We must therefore not
read from the database on the next sync. In order to avoid that, we
reset the etag of parent directories to invalid values
Fixes#1767
Or an url with '#'
Fixes#1838
The problem is a bug fixed in Qt5 now breaks.
In Qt4, QUrl::setPath() did not properly handle path with '#' in them
and QUrl::toString would restitute the '#'.
But csync will blindly do "uri + path" before passing the path to
VIO. because csync_update has no idea that the VIO plugin need special
encoding, the encoding cannot be done there. But csync_owncloud then
encodes the full path. So if the uri contains '#', it must not be already
encoded or there will be two encoding.
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.
We need to compare the other way round and compare only the file name
because our sync directory might be symlinked and then resolve to
another canonical path (but we were only interested in the filename part
anyway)
When we abort, each job currently running may result in a call to finished().
It used to cause a crash because we would unlock the _syncMutex twice
Fixes#1793
This will cause the browser window to open again after it has been told to close
if a network job has run in the background while the browser window was visible.
Fixes#1814
