will migrate invalid ietm encrypted status in the client DB when
migrating from older releases
that should ensure working synchronization by having correct tracking
of which items are encrypted
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
main issue is with child folders that were misbehaving once the initial
upload was done
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
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>
asks new permission to server to be able to know if a folder is a top
level mounted folder
should allow detecting the top level folders from external storages or
group folders
should also make the client reliably detect that it is handling a child
folder inside a group folder and be allowed to rename such folders
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>
will consider v1.2 stored encryption status in DB to be equivalent to v1
due to bugs in the v3.8.0 release
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
fetch lock properties from server
decode them and store them in sync database
test to ensure we do properly handle those properties
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
Creating a new virtual file and replacing a file with a virtual one now
have their own text in the protocol, not just "Downloaded".
To do this, the SyncFileItem type is kept as
ItemTypeVirtualFileDehydration for these actions. Added new code to
ensure the type isn't written to the database.
While looking at this, I've also added documentation on SyncFileItem's
_file, _renameTarget, _originalFile and destination() because some of
the semantics weren't clear.
If the code was not complex enough syncing two tables
already started to give UNIQUE constrains errors on
simple sync operations, this also adds initial support
remote delete of an encrypted file
Previously, there was csync_ftw_type_e and SyncFileItem::Type. Having
two enums lead to a bug where Type::Unknown == Type::File that went
unnoticed for a good while.
This patch keeps only a single enum.
This gets rid of the csync_statedb sqlite layer and use
the same code and same connection as the rest of the SyncEngine.
Missing functions are added to SyncJournalDb and change a few minor
things (like changing SyncJournalFileRecord::_modtime to be an int64
instead of a QDateTime, like it was in csync).
This gets rid of the csync_statedb sqlite layer and use
the same code and same connection as the rest of the SyncEngine.
Missing functions are added to SyncJournalDb and change a few minor
things (like changing SyncJournalFileRecord::_modtime to be an int64
instead of a QDateTime, like it was in csync).
