This change might clean up notifications that have already been
dismissed from the web ui as well.
Resolves#6624
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
should allow to speed API calls to Windows CfApi by reducing their
numbers by asking for a list of new placeholders via a single call
instead of one for each new item
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
Using the short local folder name has some interesting side effects,
such as ending up as being e.g. "C:\MySyncRoot" or "Desktop\MySyncRoot"
due to it just removing the path to the current user's home directory.
IMO using the remote path for the sidebar entry is more logical -- I
don't care where I synced it to locally, I just want to know what my
sync destination is.
To improve future maintenance I moved the generation of the sidebar
display name to a separate method, and added some quick unit tests.
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
rename FileInfo::Etags to FileInfo::EtagsAction to avoid any future
possibility that we would want to use this name for something else
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
also use `FileSystem::removeRecursively` to properly handle deletion of
read-only directories/files
There's now an integration test for this feature after all those years
as well ;-)
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
should help ensure we send a PROPFIND only when the folder etag changes
if some metadata apparently change, this is not enough to send a
PROPFIND request
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
ensure we use currently existing server API to get the "no download"
permission
requires parsing some share-attributes new DAV property
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
unfortunately does not cpature the requirements for proper long path
handling on Windows
maybe an end-to-end test could capture this requirement
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
in FilePermissionsRestore, first checks the folder permissions before
changing them
will avoid useless call changing permissions when not needed
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
Extra safeguard to ensure that the usage of
`FileSystem::setFolderPermissions` won't start a new sync run if
FolderWatcher/inotify detects a change in the file metadata...
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
On Linux changing the permissions causes inotify to create a IN_ATTRIB
event -- even if the permissions stays the same.
Such an event is passed to the filesystem watcher which lets the client
schedule a new sync run. In certain conditions, this could happen
during every sync run...
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
if Readable permissions is missing, do nto try to download the file
if a file was downlaoded but Readable permission is now missing, remove
it
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>
should improve coverage for move to trash feature to ensure this is
working as expected by users
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
Many languages have different ways of handling plurals where checking
for `n == 1` is simply not enough.
Fixes#8149
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
when propagating a rename to the child items, we must not make child
items be done from propagator point of view
they will be part of their own propagator item and that will create
issues
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
the sync engine will remove invalid items inside read-only folders
not needed to remove them in tests and rather checks that they were
indeed removed
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
