acoid modifying some metadata of the placeholder when this placeholder
has just been uploaded to the server (will avoid truncating the
timestamps)
Close#6190
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
currently unlock can happen during the sync
in that case, it may be possible that the propagator will lose the lock
state changes and override them when updating teh etag after a file has
been uploaded
detect that case and ensure we keep consistent state about files
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
in order to be able to filter some errors when showing them into the
main dialog activity list, add some more info about the error to know
the origin (like a network issue or a sync issue)
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
in order to be able to filter some errors when showing them into the
main dialog activity list, add some more info about the error to know
the origin (like a network issue or a sync issue)
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
ensure that normal sync engine will nto delete new file renamed due to
trailing/leading spaces in name
rename before upload in the same job to avoid having invalid state in
local desktop client database to ensure any subsequent run of the sync
engine will not make wrong decisions
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
when a local file has invalid date and we try to upload it, properly
handle the error such that we are not stuck forever in sync state
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
add PutMultiFileJob to send many files at once
use it in BulkPropagatorJob to implement bulk upload feature
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
If we use those encrypted propagation code paths, we already know from
the discovery phase (and thus the journal db) that the folders are
encrypted so no need to check again.
This will remove another expensive round trip with the server.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Thanks to the new discovery algorithm, we got all the freshest E2EE
information straight from the database so reuse it instead of going
through an in memory copy.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This was done because the propagator jobs where running in a thread a long
time ago, but this is no longer the case.
(Also QAtomicInt::load is marked as deprecated now)
- Close the UploadDevice to close the QFile after the PUT job is done.
This allows winvfs to get an oplock on the file later.
- Don't rely on QFile::fileName() to be valid after
openAndSeekFileSharedRead() was called. The way it is openend on
Windows makes it have an empty filename.
If one adds a new file to an online-only folder the previous behavior
was to upload the file in one sync and dehydrate it in the next. Now
these new files get set to Unspecified pin state, making them retain
their data.
Instead of all at once, to reduce peak memory use.
Changing UploadDevice in this way requires keeping the file open for the
duration of the upload. It also means changes to open(), seek(), close()
to ensure that uses of the device work right when a request needs to
be resent.
This was not required with 2.5 because a size of 0 was ignorted when comparing
size by the csync updater, to be compatible with very old version of the database.
But the we discovery will still think the file is changed if the database contains
a size of 0
