Christian Kamm [Mon, 29 May 2017 10:05:22 +0000 (12:05 +0200)]
Download: Retrigger folder discovery on 404
See owncloud/enterprise#1966
If the server and the client's database go out of sync, there could be
persistent 404 errors. This change ensures that the problem corrects
itself eventually by triggering a remote discovery of the file's
parent folders.
It does not address the root cause that might have lead to the
divergence.
Christian Kamm [Mon, 15 May 2017 12:46:09 +0000 (14:46 +0200)]
Selective sync: Skip excluded folders when reading db
When a new folder becomes selective-sync excluded, we already mark it
and all its parent folders with _invalid_ etags to force rediscovery.
That's not enough however. Later calls to csync_statedb_get_below_path
could still pull data about the excluded files into the remote tree.
That lead to incorrect behavior, such as uploads happening for folders
that had been explicitly excluded from sync.
To fix the problem, statedb_get_below_path is adjusted to not read the
data about excluded folders from the database.
Currently we can't wipe this data from the database outright because we
need it to determine whether the files in the excluded folder can be
wiped away or not.
See
https://sentry.io/owncloud/desktop-win-and-mac/issues/243433178/activity/
https://sentry.io/owncloud/desktop-win-and-mac/issues/234182688/activity/
The problem was that an account's QNetworkAccessManager can be deleted
when reentering the event loop.
Markus Goetz [Wed, 19 Apr 2017 09:02:03 +0000 (11:02 +0200)]
Server: Parse version from capabilities too #5691 (#5698)
Newer servers will have the option of hiding version, versionstring, edition
and productname. They will always send the full information in the capabilities.
Olivier Goffart [Tue, 28 Mar 2017 13:21:59 +0000 (15:21 +0200)]
PropagateDownload: fix possible crash
Backtrace looks like this:
Crash: EXCEPTION_ACCESS_VIOLATION_READ at 0x0
File "propagatedownload.cpp", line 234, in OCC::GETFileJob::slotReadyRead
File "moc_propagatedownl_CA5CFSHZDTX34X.cpp", line 86, in OCC::GETFileJob::qt_static_metacall
File "qobject.cpp", line 495, in QMetaCallEvent::placeMetaCall
File "qobject.cpp", line 1256, in QObject::event
File "qapplication.cpp", line 3804, in QApplicationPrivate::notify_helper
GETFileJob::slotReadyRead can be called with a QueuedConnection when the
bendwith manager is involved. In that case, if the QNAM was reset
in between, the reply might have been destroyed.
(This is only speculation based on the backtrace)
Olivier Goffart [Tue, 28 Mar 2017 13:11:58 +0000 (15:11 +0200)]
AccountState: Attempt to fix a crash
Backtrace from the crash reporter:
Crash: EXCEPTION_ACCESS_VIOLATION_READ at 0x21
File "qcoreapplication.cpp", line 1281, in QCoreApplication::postEvent
File "qobject.cpp", line 2125, in QObject::deleteLater
File "connectionvalidator.cpp", line 240, in OCC::ConnectionValidator::reportResult
File "connectionvalidator.cpp", line 206, in OCC::ConnectionValidator::slotAuthFailed
File "moc_connectionvalidator.cpp", line 127, in OCC::ConnectionValidator::qt_static_metacall
File "qobject.cpp", line 3716, in QMetaObject::activate
File "moc_networkjobs.cpp", line 653, in OCC::PropfindJob::finishedWithError
File "networkjobs.cpp", line 570, in OCC::PropfindJob::finished
I believe the problem is caused because 'this' was deleted in ConnectionValidator::reportResult
as the signal connectionResult gets emited. The AccountState::slotConnectionValidatorResult
slot does indeed call slotInvalidCredentials which might call {Shibboleth,Http}Credentials::fetchFromKeychain
which might emit fetched directly, which will call AccountState::slotCredentialsFetched
which deletes the _connectionValidator
So use deleteLater when deleting the _connectionValidator, hoping this helps