Add a test to test the data fingerprint feature make me realize it was broken.
The code was relying in the distinction between empty and null QByteArray,
but this was a bad idea as this difference is lost when going through QString.
The server reply with a code 400 when the token is invalid,
the client was understanding this error as a network error, and was retying
again with the same token.
Instead, we must rely on what the json is saying, even if the reply is
not a 200 code.
Issue https://github.com/owncloud/enterprise/issues/2777
The check was added for #6317 in commit
13eb64584f.
We did see missing mtimes in replies in tests with live servers though.
Possibly those were old incomplete responses cached in the stat cache?
- Adds issue_template.md to folder .github - previously bug_report.md.
- This will enable the issue template when users creates issues.
Signed-off-by: Camila San <hello@camila.codes>
Note that we also needed to adjust the server url to contains the user name
in the folder wizard. (As checkPathValidityForNewFolder expect the user name)
Issue #6654
The exact string is actually "sync.*.debug=true\ngui.*.debug=true".
And this is not strictly equivalent to setting the env var, as it
calls QLoggingCategory::setFilterRules.
Over all, that's an implementation details that users do not care about.
Not having these enabled by default is causing significant extra back
and forth with reporters since they must manually use --logdebug for the
log to be useful.
Fix a strange warning seen on the log from the CI on Windows in
https://github.com/owncloud/client/pull/6621
The test shows, at the beginning
QObject::connect: No such signal DesktopServiceHook::destroyed(QObject*)
And crashes at the and.
My guess is that when QDesktopServices::setUrlHandler is called, the
QMetaObject is not yet initialized
But this is probably not the reason of the crash
