The server keeps the mtime and etag anyway.
And changing the mtime also changes the etag and so make other clients re-download
the file instead of detecting the move
The fields varialbe should contain or'ed flags of the fields set
in the csync_vio_file_stat_t struct. The problem was that the field
for CSYNC_VIO_FILE_STAT_FIELDS_PERM was assigned rather than or'ed
which makes the release function for the struct not freeing the
etag memory => memleak.
When recovering from a inalid move operation, we call
avoidReadFromDbOnNextSync. This will remove the fileid from the db so
we don't detect a move on the next sync. But we want the next sync to fetch
the file id again, and this can only happen if we don't read them
from the db and do the actual PROPFIND, this is done by avoidReadFromDbOnNextSync
However, if there is propagation in that source directory later, it
will overide the invalid etag with the real one and we will not uissue the PROPFIND
to fetch the fileid.
We must therefore also protect the future write to the DB when calling
avoidReadFromDbOnNextSync
Some PUT, may take a long time on the server to process (for example, the
last chunk). It may take more time that the timeout.
So in that case the server may reply with an url that we can poll for the etag
This patch is still work in progress
Otherwise the buffer might fill up too quickly and get too large and consume
too much memory which could lead to crash in extreme cases
Should fix issue #1974
When using the "Limit automatically" limit, we wait for 25% of the time
it took to upload something.
However, if we go to sleep while uploading, the time it took to upload may take
days. And waiting for 25% of a day is too long.
So never wait for more than 10 seconds
This may be related to issue #1880
If the local folder changes, the sync has to be reinitialized as
well. Until now we did not detect that, which led to the case that
the sync folder was not reinitialized in case only the local folder
changed in the setup dialog.
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
