If the file has a mangled name or will end up in a parent directory
known to be encrypted, we stick to the CSYNC_INTRUCTION_NEW instead of
going for CSYNC_INSTRUCTION_RENAME. This way we'll have a delete and an
upload instead of a move command.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
When the ClientSideEncryption object is fed, also serialize the
encryption info of the folders inside the metadata table.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This will allow to exploit the information of a directory being
encrypted or not during the discovery phase.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This will turn useful for other consumers of that data. The alternative
would be to expose a method breaking all form of encapsulation.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We used to do it when the propagation starts, let's do it even before
the discovery starts. This way we'll have a chance to exploit the
information during the discovery phase.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
- The code handling the api response was not up to date with the latest
api changes.
- Unlimited quota display: use qint64 to avoid data loss
- Change total with quota: total holds the quota total and not the storage total.
Signed-off-by: Camila <hello@camila.codes>
Update systray behavior and context menu:
- left click brings up the new QtQuick based dialogs on all latforms
- right click brings up the new QtQuick based dialog on Mac OS only
- right click brings up a context menu on all other platforms than Mac OS
- "Quit Nextcloud" => "Exit Nextcloud"
- Add "Open main dialog" option.
Signed-off-by: Camila <hello@camila.codes>
With the current design of the file upload this necessarily pushed to a
lock starvation on the folder. Indeed you could end up with N jobs
asking for the lock at the same time. So just avoid parallelizing for
now even though it will be slow.
We could try to optimize but that'd require some serious changes to the
sync logic on the jobs... let's stabilize first and optimize later.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
During the wizard we currently don't have much information about the
encrypted folders. In particular we can only display their mangled names
which is far from ideal for the user to make an informed choice.
That's why in the wizard we now forbid creation of subfolders in e2ee
folders and we also don't display subfolders of e2ee folders.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Since the e2e oracle works only in term of absolute remote paths and
that our model x._path was relative, we need to properly convert.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
In such cases we get a download for which _file is already the demangled
name and _encryptedFileName has the mangled information. This is
different to what we encountered so far where initially _file was
mangled and _encryptedFileName was empty. Let's deal with that case
properly.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise on second sync we wouldn't find anything under a mangled path
and just end up thinking said files were removed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise, after a first sync all the mangled entries would be removed
from the journal. On second sync it would be fine because we'd then have
seen the unmangled names because of the local files. Unfortunately
that'd mean reuploading them for nothing or trying to mkdir again on the
server for nothing... with a chance of using differently mangled names
(although I didn't spot it, I can't exclude it never happened).
This also led to weirdly getting stuck during sync when there was more
than one sync point.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Yes... I still wish this would be all driven by the type system, would be
much less error-prone.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
I wish this would be all driven by the type system instead of
error-prone string concatenation everywhere. That will be for a (much)
later refactoring hopefully.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
It turns out this job expected an absolute remote path even in the case
of a subfolder sync point.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This was half broken before that commit and the previous one since some
of the categories would not be captured.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise it was a bit confusing and annoying for filter rules:
e.g. "nextcloud.sync.*" vs "sync.*".
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This means adjusting PropagateDownloadEncrypted so that it knows where
the file will end (otherwise it would create temporary files in non
existant paths for instance).
In turn we have to adjust PropagateDownloadFile accordingly so that it
resolves the local folder the file will end up in.
And last we adjust PropagateLocalMkdir to resolve paths as well and
demangle as needed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
