To better see what is going on when and if files are removed by the
client.
See also: #260, #1433, #2913
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
We should not rely on the product name because it is something the
user can change in the theming options on the server.
Fixes#3001
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
If the get job got an authentication required error on the account url
(not davUrl! at that stage we always get auth error there), then it is
safe to assume basic auth is used on the server. It is then kind of
pointless to use any other auth mode they will necessarily fail. Only
basic auth will do the job so force it.
Signed-off-by: Kevin Ottens <kevin.ottens@enioka.com>
This is necessary to be able to distinguish between "I decided on basic
by default" and "I didn't write any auth type". To make sure all the
jobs end up writing something we then implement the "I decided on basic
by default" in the slots connected to the job and we assert it in
checkAllDone()
Signed-off-by: Kevin Ottens <kevin.ottens@enioka.com>
There were a couple of shibboleth related enums left, since that auth
method isn't supported anymore remove the code tied to those enums. It
was dead code anyway.
Signed-off-by: Kevin Ottens <kevin.ottens@enioka.com>
When the client runs and a conflict gets detected, the sync engine runs
two times.
On the first run, the sync engine detects the conflict, marks the
file as a conflict and propagates that to the GUI. This leads to an
error notification with the original filename in the main dialog.
The sync engine runs then a second time. On this second run, the file
that originally caused the conflict is not anymore a conflict
file. Instead, the sync engine detects the conflicted copy and
propagates that file as a conflict to the GUI.
When opening the conflict dialog with the original file name (not the
conflicted copy) a crash happens. Usually, the two sync runs are really
fast, so the user does not notice the first notification. However, a
problem can occur if a conflict gets created while the client is not
running. Since then, the client does not do two sync runs. It does only
run once.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
Added the configuration options
confirmExternalStorage
crashReporter
newBigFolderSizeLimit
useNewBigFolderSizeLimit
to the Windows registry
Signed-off-by: Marco Hald <marcohald@users.noreply.github.com>
Indeed the path we have is supposedly not fully qualified in case of a
sync folder which doesn't point to / on the remote end. But LSCOL works
with absolute paths on the server so make sure this is what we give it
out.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This got broken during the huge discovery refactoring. I wrongly passed
the mangled name as is out of discovery, but coming from listing jobs it
was fully qualified while the jobs at propagation time and the db expect
those paths to be relative to the remote folder.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Compiling nextcoud gui as a separate library. This is needed to more
easily write tests. The whole nextcloud application can now be linked
against the tests.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
I went full steam on making it all public which is not really required,
it's only really QtWebSockets we're after. Could always be fine tuned
later on if this works as expected.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This would only happen if the parent of the newly created folder would
be explicitly set to online only, hence why it went under the radar
previously.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This account object was really only used during the initialization phase
or for forgetting the sensitive data. So let's receive it as parameter
there and pass it on from job to job as needed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The OS might request the same file again if we take too much time to
fulfill a request. So in case it's queueing the same one again instead
of bailing out just fail the second one and let the first one finish
properly.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
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>
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>
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>
