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>
should prevent a malicious server admin to make clients fallback to
older vulnerable metadata format
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
introduce a new type of conflict for case clash filename conflicts
add proper handling including a new utility class to solve them and a
new dialog for the user to pick a fix
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
in case some propgation actions ends up with a BlacklistedError, we
would skip the deletions of local folders (even though they have been
deleted from server)
let's not skip them but rather keep track of the error status and
properly report them
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
ran
run-clang-tidy-14.py -header-filter='.*' -checks='-*,cppcoreguidelines-pro-type-static-cast-downcast' -fix
this can prevent casting to a type that is unrelated to the real type
and later cause a crash because you go into undefined behavior domain
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
no need to print a line each time we check for a name clash
always print a line when a clash is detected
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>
When the client runs and a conflict gets detected, the sync engine runs
two times.
On the first run, the sync engine detects the conflict, marks the
file as a conflict and propagates that to the GUI. This leads to an
error notification with the original filename in the main dialog.
The sync engine runs then a second time. On this second run, the file
that originally caused the conflict is not anymore a conflict
file. Instead, the sync engine detects the conflicted copy and
propagates that file as a conflict to the GUI.
When opening the conflict dialog with the original file name (not the
conflicted copy) a crash happens. Usually, the two sync runs are really
fast, so the user does not notice the first notification. However, a
problem can occur if a conflict gets created while the client is not
running. Since then, the client does not do two sync runs. It does only
run once.
Signed-off-by: Felix Weilbach <felix.weilbach@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)
By introducing a PropagateRootDirectory job that explicitly
separates the directory deletion jobs from all the other jobs.
Note that this means that if there are errors in subJobs the
dirDeletionJobs won't get executed.
