This got broken previously when trying to reconcile during a
cherry-pick. This also repairs the case when the theme tells us the
default is to not select anything (not that we're using this right now
but in case we'd like to brand this).
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We now favor APPLICATION_ICON_SET to isBranded() regarding the decision
to use PNG or SVG for icons.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Indeed, that file size will almost always change between the 1 byte
placeholder and the hydrated file. Only when using the CfAPI on Windows
this won't be the case since because it will expose the original size
even for placeholders.
Also worth noting: the suffix backend didn't hit that case since the
filename changes (with suffix for placeholders, without for hydrated
files).
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Ideally this will end up being the backend we use for both Linux and
macOS but that will require work with desktop environments on the Linux
side and to reverse engineering at least on xattr value on macOS.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
There's been a confusion between the chunk number and the chunk
offset leading to corruptions... Let's pass the proper offset to
the UploadDevice again.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
MSVC having so useless error messages it didn't quite point to the root
cause of the issue... it turns out that through the maze of macros
defined in the windows API, there's one which impacted the function
pointer definition of CfCloseHandle which would then not convert to
FileHandle::Deleter as expected. So I end up wrapping it in a lambda to
help... luckily this kind of lambdas decay into a simple function
pointer so there's likely no overhead it's just to coerce the compiler
into doing the right thing.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
For some reason MSVC manages to deduce the right constructor in Win64
mode but not in Win32 mode. So let's be more explicit about what we
return.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise this would attempt to download the file everytime we check the
direct editor for a given file which wouldn't be adequate. Would also
lead to a deadlock in our case since that would happen in the main
thread and implicit hydration is driven from there as well.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This comes with a test simulating an open request coming from another
process (although in our case it's really just a thread). The actual
hydration works as expected by cfapi, handling of encrypted files is for
now missing.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
For now this implements only the logic necessary to get a test suite
equivalent to the TestSyncVirtualFiles one to pass. It doesn't (yet)
honor request to fetch files from the system.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Shouldn't be translated.
Just checked https://en.wikipedia.org/wiki/HTTP_ETag and all available localized pages.
Signed-off-by: rakekniven <mark.ziegler@rakekniven.de>
