PROPFIND timeout: show folder with error, and don't abort sync run

[michaelstingl]

An user added 25k PDF files to a single folder. (7GB in total) this is obviously too much for the ownCloud server and causes erratic behaviour. Needs to be fixed on the server-side, but maybe the client can also be improved a little bit.

ownCloud client 2.4.2 shows timeout error, but doesn't display which folder caused the timeout:

10-18 07:43:37:234 [ info sync.networkjob.propfind ]: PROPFIND of QUrl("https://cloud.example.com/remote.php/dav/files/user123@domain.com/") FINISHED WITH STATUS QNetworkReply::NetworkError(NoError) ""
10-18 07:44:04:792 [ warning sync.networkjob ]: Network job timeout QUrl("https://cloud.example.com/remote.php/dav/files/user123@domain.com/PDF-1")
10-18 07:44:04:793 [ warning sync.networkjob ]: QNetworkReply::NetworkError(OperationCanceledError) "Connection timed out" QVariant(Invalid)
10-18 07:44:04:794 [ info sync.networkjob.lscol ]: LSCOL of QUrl("https://cloud.example.com/remote.php/dav/files/user123@domain.com/PDF-1") FINISHED WITH STATUS QNetworkReply::NetworkError(OperationCanceledError) "Connection timed out"
10-18 07:44:04:795 [ warning sync.discovery ]: LSCOL job error "Operation canceled" 0 QNetworkReply::NetworkError(OperationCanceledError)
10-18 07:44:04:796 [ warning sync.csync.updater ]: opendir failed for PDF-1 - errno 5
10-18 07:44:04:797 [ warning sync.engine ]: ERROR during csync_update : "An error occurred while opening a folder Operation canceled"

The new ownCloud client 2.5 produced the same error.

It would be smart to list at least the folder name in the error message. It took the user pretty long time to find out which folder of the customer was causing this problem. By unselecting this folder, the sync could continue and finished successfully.

The really annoying issue is that the ownCloud client starts checking the content over and over again - but this time at least we could see the folder name which was causing the problem.

Maybe this should be added to #5859 (Never ever abort sync runs…)

Expected behaviour

• Errors messages related to a folder should display the name of the folder
• Errors with individual folders shouldn't abort the sync run. Client should proceed with the next folder.

Actual behaviour

• No folder name is shown in some

Steps to reproduce

1. Add 25k PDF files to a subfolder on the oC server
2. Let the sync client perform the discovery (PROPFIND)

Server configuration

n.a.

Client configuration

Client version:
2.4.2, 2.5.0

Operating system:
Win, Mac

OS language:
EN, DE

@owncloud/desktop-core-developers Any idea what can be improved here?

00010651

[guruz]

I think we can at least get the folder name showing into 2.5.1.
"Operation canceled" is indeed a timeout. We can't easily distinguish between network timeout and "server is working too long"..

[ckamm]

This PR adds the folder path to the error message: #6850, moving the rest of the ticket to 2.6

[ckamm]

Note that for 2.6 it'd be nice to improve error message strings. Currently they are unpretty like "An error occurred while opening a folder B: Operation canceled" since I didn't want to touch translated strings for 2.5.1 and keep the change minimal.

[ckamm]

Directory discovery job errors like this one are still fatal in 2.6. I'll look at making them non-fatal.

[ckamm]

After discussing with @ogoffart in the proposed PR #7134: It seems error prone to continue when the remote data couldn't be fully updated. Let's not do that and instead solve the problem of remote discovery needing to restart from scratch after an abort with something like #2976.