When owncloud is restored, at boot time, it might be started before the
crendential manager. So if we detect an error, wait 10 seconds and hopefully
it'd be loaded by then.
Issues: #4274, #6522
Some servers have virus scanners and the like that can delay the
response of the final chunked upload assembly significantly, often
breaking the current 5min (!) timeout. See owncloud/enterprise#2480
for details.
Previously it tried to abort even jobs that had already finished, which
was not going to work as they wouldn't emit finished() again.
Also, in some cases the abortCount would never go to zero and that case
wasn't well documented.
Since commit 4dc49ff3, we store an entry in the upload info table even
for non chunked uploads. However, if this fails we don't want to remove
non-existant stale chunks if the upload fails.
Without this commit, we would send a DELETE command to clean non-existant
chunks in the dav/uploads/ namespace.
We otherwise normalize all path in the C form, so we must have
the Folder's path normalized the same. Or all comparizon will fail
(such as knowing if a file from the SocketAPI or the FilesystemWatcher
are part of the folder)
Issue #4424
If the SyncResult incorrectly believes that there are no conflicts, the
tray icon won't be correct and there will be no warning about unresolved
conflicts on the account.
Nevertheless, it's pretty awkward that the IssuesWidget is better
informed about pending conflicts than the Folder itself. This kind of
backwards data flow is very confusing.
Unfortunately the only alternative I see is to either keep track of
this information in two places (also in Folder), or create a common
data-holding class that can serve as a model instance for the issues
view as well as provide data directly to the Folder - which would
have been a much larger change.
Everything is invalidated later: after discovery, not before. In
addition entries that should only be invalidated when new local
discovery is done have that behavior now.
(PR #6265)
- Remove the UI completely
- Move the #ifdef inside the FileSystem::moveToTrash function, so it is easier to
implement on other platforms
- Q_OS_UNIX includes mac, so we need to disable it. (not using Q_OS_LINUX because of
other BSD that uses XDG spec as well
- Translate the error messages
- Add a couple of doc comments
QFileInfo::isSymLink() does detect reparse points that are symlinks but
returns false for junctions. The new function FileSystem::isJunction()
can detect those and is used to not recursively delete files inside
directories that are junctions.
See also https://bugreports.qt.io/browse/QTBUG-45344 and the
discussion in the PR https://codereview.qt-project.org/#/c/113019/.
