The legacy job might still need the neon session and the propagator.
We need to make sure the thread exits before.
This fixes crash when pausing a sync made with the legacy jobs
(for example when there is network limitation)
This should fix https://github.com/owncloud/enterprise/issues/200
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)
