Use the right check to determine whether a file has a blacklist entry,
SyncFileItem::FileIgnored was incorrect because that denotes files from
the ignore list or blacklisted files with no retries left.
The blacklistedInDb flag does the right thing. Rename it to
hasBlacklistEntry to be more explicit.
* Downloadinfo entries for files that no longer need to be downloaded
are useless and can be removed. In particular, the temporary files
holding partially retrieved files are now deleted when no longer
necessary.
* The same is true for blacklist entries for paths that are no longer
being discovered.
* Same for uploadinfos for files that no longer need to be uploaded.
Handle problems which happen because of pausing the sync as soft errors
rather than normal errors which are blacklisted and displayed in the
gui.
This fixes bug #1959
While uploading a new folder, if the folder is renamed on the server
when still uploading, the result will be that the files that are already
uploaded will end up in the new filder name, but the file that were
not still are in the old folder.
After renaming, all the new uploads wil fail with an error on this sync
because the parent directory don't exist.
But they were uploaded with the old name in the next sync because
the renaming was not detected because the file id was not in the DB
Fix the problem by fetching the file id always when creating a new
directory, on the next sync, and saving it in the database ummediatly
https://github.com/owncloud/enterprise/issues/191
If the result of a restored directory is SoftError, this prevent
to sync the rest of the directory
Therefore, we introduced a new status Restored, which means that
the job was a success, but is a restoration and therefore should be
seen as a warning
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
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
It should not create a conflict in that case.
Also when editing a file, create a conflict using the normal way,
after downloading the file and checking it is not the same
