We should probably make this at least a visible error, because it's a
limitation set by the kernel/the distro and we would require root
permissions to adjust the value.
Right now all that happens is that syncing is not immediate, but only
run every 30 secs (due to server polling).
SyncPrepare is when the folder class prepares the actual syncing,
i.e. does treewalks and runs the reconceiler in case of mirall. The actual
SyncRunning state will only be entered if there is actually anything to
sync.
Fixes#289
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
Some load balancers may add more cookies, and we would pick the wrong
one. So keep all the cookies.
If we already read a session cookie, don't parse more cookie as they are
not session cookie.
This patch contains a few (source-compatible) API additions needed for
the Plasma client.
* return QNetworkReply* to caller for tracking status and error of
requests such as mkdir, getWebDAVPath and getRequest
* Add a setter for the QNetworkAccessManager. This allows us to route at
least some of the network requests through KIO in the Plasma client
* Add a setter for the remotePollInterval. This should be enough API to
* make it possible to adapt the polling interval to the client's machine
state, e.g. sync less often on battery, or somesuch
