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>
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>
the new method added to query the db is not working and so the fix for
vfs is executed at each sync run
the new method for bool was not really needed so let's just remove it
(and that will make the usage of SqlQuery be correct
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
In the past not all files were converted to placeholder files when
converting an existing sync folder to a virtual files folder. Because
some files were not converted to placeholder files, the status would
be wrong on the files. This code makes sure that every file in a
virtual files folder is a placeholder file. It could be removed in the
future.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
This key value store should help to keep track of important events,
that can not be store in the logs, because the logs are deleted too fast.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
We also don't have a version entry in the db if thne db is new.
As I don't expect regular updates from 1.5 this message can just be removed.
Fixes: #8004
Previously the pin states of deleted files stayed in the 'flags'
database and could be inadvertently reused when a new file with the same
name appeared. Now they are deleted.
To make this work right, the meaning of the 'path' column in the 'flags'
table was changed: Previously it never had the .owncloud file suffix.
Now it's the same as in metadata.path.
This takes the safe parts from #7274 for inclusion in 2.6. The more
elaborate database schema changes (why use 'path' the join the two
tables in the first place?) shall go into master.
The previous patch ensured that the sqlite temporaries weren't deleted
and recreated for every sync run, but there was still time between
client startup and the first sync run where they would have the
"needs-sync" icon.
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.
The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.
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
