Since QNonContiguousByteDeviceThreadForwardImpl::reset will
call UploadDevice::reset with a BlockingQueuedConnection, this
allows us to reset the HTTP channel along with its buffers
before they get the chance to be reused with a subsequent request.
This is largely a guess, but this is the only place where we use
a QIODevice to push data through QNAM and that the QIODevice isn't
a direct child of the QNetworkReply.
Fix the issue by making sure that we don't go back to the event loop
and possibly handle network events between the destruction of the
upload QIODevice and the QNetworkReply, which might lead to QNAM
dereferencing a dangling QIODevice pointer.
QFileInfo has to be refreshed if the underlying file has been
modified in between. That is dangerous so ckamm and me decided
to eliminate the QFileInfo based implementations.
This was triggered by a bug that the client uploaded files that
it should not have.
This crash was uncovered when testing parallel chunks when one chunk
finished the upload. The propagate was then finished with the other
UploadDevices still being in-flight in the QNAM.
This should solve #2675 and #1981
By preloading the chunks in memory before sending them, we don't keep the
file open and therefore we let other program open the file for writing.
If the file is modified between two chunks, we detect that and abort anyway
The server is slow to process each chunk. As a result the time between
the chunks is not neglectible. Therefore we gain a lot of time by
uploading the chunks in parallel. So the bandwitdh is used when the
server is waiting between chunks.
* Use a shared pointer to Account everywhere to ensure
the instance stays alive long enough for a sync to terminate
* Folder is now tied to an AccountState
* SyncEngine and OwncloudPropagator tie to an Account and use that
for all jobs they run
Issue: Since the setup wizard currently always replaces the
account, it will always wipe all folder definitions, even when
the actual changes to the account were minor.
