report status when the job is in error at end of hydration request
instead of doing the opposite
properly set status in db when a file failed to hydrate (still a virtual
file not a real one)
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
sometime it can be called with a path that is already deleted
ensure we always go to the correct code path
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
_com_error(cfExecuteresult).ErrorMessage() calls should be translated to
QString before use with qDebug and related logging facilities
Signed-off-by: Matthieu Gallien <matthieu.gallien@nextcloud.com>
files that get downloaded not through an hydration request need to be
converted to placeholder
sets the expected state when converting them to placeholder files
#3082
Signed-off-by: Matthieu Gallien <matthieu_gallien@yahoo.fr>
when using Cloud Filter API with enabled VFS on Windows, a progress bar
stays visible for some time after hydration is completed. Not updating a
last time the progress bar prevents that.
Signed-off-by: Matthieu Gallien <matthieu_gallien@yahoo.fr>
sets a reasonable size of the StructSize members in the struct passed to
CfRegisterSyncRoot function
Signed-off-by: Matthieu Gallien <matthieu_gallien@yahoo.fr>
In case we'd been to slow to fullfill or we're still processing a
cancelled request better not just crash. We still log the issue though.
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>
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>
allexzander
James Horsley
Matthieu Gallien
rakekniven
Dmytro Korchynskyi
Hannah von Reth
Felix Weilbach
Matthieu Gallien
Kevin Ottens