we may not currently properly store certificate hash for encrypted items
and later fails to find which public or private key pairs to use
for now, it is better to remove it and ensure we have a reliable way to
handle certificate migration
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
Files with a modification time of less than 0 do usually not make sense
(and afaik the server doesn't accept them either).
--> attempt to update the modification time to _Time.now_ while
propagating
side note: I ran into this because KArchive/Ark(?) didn't consider the
extra time attributes on entries for a certain zip file, so it instead
used the standard time value of each zip entry which was set to <= 1980
for files and < 1970 for directories...
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
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>