This fixes mirall#1132
A variable that counts the affected items of the propagator operation
done on a item was added to SyncFileItem. Usually that is 1 because
most operations affect only the item itself. But for removes, the
number can be higher for directories (one remove removes a whole tree).
Some rearrangements were needed.
503 for directories means that the dir is a mounted directory from an
external mount which currently is not available. The directory is
ignored and not traversed into during discovery phase.
As described in http://www.sqlite.org/cvstrac/wiki?p=MultiThreading precompiled
statements should not be used across thread borders. However, the reconcile
phase would reuse the statements if defined (it calls statedb function from
a different thread) so it is saver to finalize them at the end of the
update run.
It is possible that we have should_update_etag set to true for files
that we also need to propagate. In which case we must not write to the DB
too early as this could cause data loss. (cf: issue #2296)
In the sync engine. Because that makes tha tthe lower_bounds in selective sync works properly.
For example, if both "Test" and "Test Test" are in the list, then "Test/Foo" would match the "Test Test"
because slash is after space
Task #2289
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.
A top level shared dir can always be removed on the client, even if it is
read only shared. In that case, the removal means "unsharing". Fixed the
permission check accordingly.
See bug #1918 for more information.
Before, 0 was used to indicate the sync start which wipes the activity
window. However, if there _are_ no synced items but only ignored items
the overall counter stays zero which wipes the list all the time.
This fixes bug #2171
* 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.
Before, we would only detect it if all the files were removed, and no
file where added or changed. This may not be enough because there might
be a welcome.txt file. Now, we check that none of the file stays the same,
and some files are removed.
Relates issue #1948