orignally added by https://github.com/owncloud/client/pull/6632
most probably a too strong assumption on the behavior of the Nextcloud
server
better check real item metadata like fileid, size or modification time
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
we rename the top folder and we rename a not direct child that is also
moved to another folder below the original renamed top folder
so
a/b/c
a/b/d/file
will be
e/b/c/f/file
with
a -> e
d-> f
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
this new test trigger the assert that a file is either in the old place
or the new place when we execute a MOVE instruction for a local file
in the test one file is discovered as in need of a local MOVE but will
be missing from the old and new places when running the propagation due
to a bug
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
current automated tests are never breaking the rule that a file that
should be moved on client side (after a move was done server side)
exists either at teh original path or the destination path.
in practice it may happen (and I manually tested it) thet the sync
engine decides to move a single file in two distinct places
that decision will violate this rule and a debug build would then run
into the assert
Close#6462
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
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.
As far as I'm aware local discovery can be skipped on folders that are
selective-sync blacklisted, so a local discovery is required when an
entry is removed from the blacklist.
Also rename
avoidReadFromDbOnNextSync() -> schedulePathForRemoteDiscovery()
since the old name might also imply it's not read from db in the local
discovery - which is not the case. Use Folder::
schedulePathForLocalDiscovery() for that.
For duplicate file ids the update phase and reconcile phase determined
the rename mappings independently. If they disagreed (due to different
order of processing), complicated misbehavior would result.
This patch fixes it by letting reconcile try to use the mapping that the
update phase has computed first.
When users share the same tree several times (say A/ and A/B/ are both
shared) the remote tree can have several entries that have the same
file id. This needs to be respected in rename detection.
Also adds several tests and fixes for issues noticed during testing.
See #6096
