search

owncloud / client

🖥️ Desktop Syncing Client for ownCloud
GNU General Public License v2.0
1.4k stars 668 forks source link

When server has external storage the folders to sync dialog times out waiting for the server reply #3524

Closed phil-davis closed 8 years ago

phil-davis commented 9 years ago

owncloud-too-big-folder-01

Expected behaviour

After the end-user of the client is notified that "There are new shared folders that were not synchronized because they are too big", it should be obvious to an end user what to do next and how to choose to synchronize the new folder/s.

Actual behaviour

I click the Apply button in the screenshot. Then I cannot find where to go to choose which folders to sync. I am an IT guy, if I can't work out where to find the button to edit which folders are synced then I am sure our users will not be able to find it :) In this case I am using multi account and have 2 accounts connected up to the same server - but I suspect this will not be part of the issue here.

Steps to reproduce

  1. On account A client set "Ask confirmation before downloading folders larger than" to some low value (e.g. I did 5MB)
  2. On account B on the server share some folder >5MB with account A
  3. On account A client the "too big" notification is received, good. Click Apply.
  4. Now you want that folder to be synced - try to work out how to get account A to sync it - I can't.

    Server configuration

Operating system:

Web server:

Database:

PHP version:

ownCloud version: 8.0

Storage backend:

Client configuration

Client version: 2.0.0-nightly 20150731 (build 5317)

Operating system: Windows7

OS language: English (US)

Installation path of client: default Windows path

Logs

phil-davis commented 9 years ago

On 1.8.4 (build 5267) (single account Windows client) when I click on the account I see good buttons on the right-hand side: Add folder Pause Remove Choose What to Sync

and Account Maintenance buttons to the right of "Storage Usage" for: Edit Ignored Files Modify Account

If these functions appeared somewhere that I could find them, then I expect all would be well.

phil-davis commented 9 years ago

Is the ability to "choose what to sync" just hidden somewhere in the UI that I cannot find? (i.e. it needs documentation, user education and/or improvement to the UI to avoid the need for user education) Or have the buttons accidentally gone missing? (i.e. it is a plain old bug to be fixed)

phil-davis commented 9 years ago

I connected to my personal ownCloud at the same hosting service as the corporate ownCloud. The personal one shows the choice for which folders to sync: owncloud-choose-folders-to-synch1 So now I know to expect the tree of folders to sync to be a "dropdown" like in that screenshot above. The corporate one does not show the folders to sync: owncloud-choose-folders-to-synch2 Hmmm - now I will think about how the corporate ownCloud server could be different or?

dragotin commented 9 years ago

is the corporate ownCloud a huge one? Maybe listing of the server folders takes its time?

Tested the similar setup here, works nicely.

jancborchardt commented 9 years ago

is the corporate ownCloud a huge one? Maybe listing of the server folders takes its time?

Then we should add loading feedback (like a spinner) while the request runs.

phil-davis commented 9 years ago

Both are very small. We are just starting out. I will play some more this evening. The corporate one authenticates to our IMAP email server, using email address+email password. My personal one just has real local users set up. But that should not make any difference. Also I get the choose folders to sync fine for the corporate one on a Windows7 desktop running ownCloud client 1.8.4.

dragotin commented 9 years ago

@phil-davis great, thanks. Please do not forget to record a client log file when testing.

phil-davis commented 9 years ago

The issue is with External Storage. I had some External Storage defined in the corporate ownCloud. That storage was read-only to the corporate ownCloud and shared to everyone. When I defined the same External Storage in my personal ownCloud, then the tree of folders to sync would not open in the 2.0 client (at least on Windows). I removed the External Storage from each ownCloud server in turn. As I removed the External Storage, the respective account/s on the client would sync, delete the folder locally, and then the tree of folders to sync was visible again. Note that client 1.8.4 can display the folders to sync even when there is External Storage. So I guess there is a regression here somewhere in the way all that was enhanced for multi-account.

ogoffart commented 9 years ago

@phil-davis i don't know what the problem could be. Perhaps you could look in the log what it says when you try to open the folders?

phil-davis commented 9 years ago

This is in one of my many browser tabs to do! I will play with some remote storage over the weekend and see exactly what I can do to reproduce this.

phil-davis commented 9 years ago

Problem is the same if I add an external storage from the cloud administrator and share it with [someone|everyone] on that cloud and if I create the external storage directly as just an ordinary user.

ownCloud Client 2.0.0beta1 connecting to ownCloud server 8.0

  1. The ownCloud client shows the current list of possible folders to sync correctly.
  2. On the server, add the external storage however you like, and wait for it to sync down on the client. (I added an external storage on another ownCloud)
  3. Open the folders to sync drop down. The new folder is not shown. Not good, but that is a known issue anyway that the list is not refreshed on each arrival of a new folder.
  4. Quit ownCloud client and stat it again and wait for it to have done its initial checks/sync.
  5. Open the folders to sync drop down. No folders are shown.

I can replicate this easily without doing anything unusually tricky, so I am hoping that it can be easily reproduced in the lab also.

phil-davis commented 9 years ago

On startup it all looks good for the initial in-sync checks. Folder "Zf1" is the external storage I added for testing and that folder and files in it appear in the overall sync check. Here is a chunk of log output that might have the interesting bits. "Failed to resolve EGL function eglGetPlatformDisplayEXT" does not look great, but those messages also appear if I start up with no External Storage.

08-09 16:14:51:566 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Documents/INF Cloud.doc
08-09 16:14:51:568 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: T42/IMG_2066.JPG
08-09 16:14:51:570 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Photos/Today/100_3581.JPG
08-09 16:14:51:573 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Photos/1982-05-08 Our Wedding/scan0096.jpg
08-09 16:14:51:574 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Zf1/Class1 maths.pdf
08-09 16:14:51:576 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Zf1/Class 2 English.pdf
08-09 16:14:51:578 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Photos/1982-05-08 Our Wedding/scan0054.jpg
08-09 16:14:51:580 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Photos/1982-05-08 Our Wedding/scan0052.jpg
08-09 16:14:51:581 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Photos/Today/100_3604.JPG
08-09 16:14:51:583 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Zf1/Class KG maths.pdf
08-09 16:14:51:585 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Davis-Photos/1982-05-08 Our Wedding/scan0070.jpg
08-09 16:14:51:586 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server dir:  Davis-Photos
08-09 16:14:51:589 0x48c7798 _csync_merge_algorithm_visitor: INSTRUCTION_NONE     server file: Zf1/Class 5 English.pdf
08-09 16:14:51:591 0x48c7798 csync_reconcile: Reconciliation for remote replica took 0.17 seconds visiting 101 files.
08-09 16:14:51:593 0x48c7798 csync_statedb_close: sqlite3_close=0
08-09 16:14:51:595 0x48c7798 OCC::SyncEngine::slotDiscoveryJobFinished: <<#### Reconcile end ####################################################  1973
08-09 16:14:51:600 0x48c7798 OCC::SyncEngine::slotDiscoveryJobFinished: Permissions of the root folder:  "RDNVCK"
08-09 16:14:51:602 0x48c7798 OCC::SyncJournalDb::commitInternal: void OCC::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit  "post treewalk" and starting new transaction
08-09 16:14:51:605 0x48c7798 OCC::SyncJournalDb::commitInternal: void OCC::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit  "post stale entry removal" and starting new transaction
08-09 16:14:51:608 0x48c7798 OCC::OwncloudPropagator::start: Using QNAM/HTTP parallel code path
08-09 16:14:51:610 0x48c7798 OCC::SyncEngine::slotDiscoveryJobFinished: <<#### Post-Reconcile end ####################################################  1989
08-09 16:14:51:634 0x48c7798 OCC::SyncEngine::slotJobCompleted: void OCC::SyncEngine::slotJobCompleted(const OCC::SyncFileItem&) "" INSTRUCTION_NONE 0 ""
08-09 16:14:51:637 0x48c7798 OCC::SocketApi::sendMessage: SocketApi:  Sending message:  "STATUS:OK:F:\Davis-ownCloud\"
08-09 16:14:51:640 0x48c7798 OCC::SyncJournalDb::walCheckpoint: void OCC::SyncJournalDb::walCheckpoint() took 0 msec
08-09 16:14:51:642 0x48c7798 OCC::SyncJournalDb::commitInternal: void OCC::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit  "All Finished." 
08-09 16:14:51:646 0x48c7798 OCC::SyncEngine::finalize: CSync run took  2025
08-09 16:14:51:648 0x48c7798 OCC::BandwidthManager::~BandwidthManager: virtual OCC::BandwidthManager::~BandwidthManager()
08-09 16:14:51:658 0x48c7798 OCC::Folder::slotSyncFinished:  - client version 2.0.0beta1 (build 5372)  Qt 5.4.0  SSL  OpenSSL 1.0.2d 9 Jul 2015
08-09 16:14:51:661 0x48c7798 OCC::Folder::slotSyncFinished: -> SyncEngine finished without problem.
08-09 16:14:51:675 0x48c7798 OCC::Folder::bubbleUpSyncResult: Processing result list and logging took  11  Milliseconds.
08-09 16:14:51:677 0x48c7798 OCC::Folder::bubbleUpSyncResult: OO folder slotSyncFinished: result:  2
08-09 16:14:51:680 0x48c7798 OCC::SocketApi::sendMessage: SocketApi:  Sending message:  "STATUS:OK:F:\Davis-ownCloud\"
08-09 16:14:51:682 0x48c7798 OCC::SocketApi::sendMessage: SocketApi:  Sending message:  "UPDATE_VIEW:F:\Davis-ownCloud\"
08-09 16:14:51:684 0x48c7798 OCC::ownCloudGui::slotComputeOverallSyncStatus: Folder in overallStatus Message:  OCC::Folder(0x640bca0)  with name  "ownCloud"
08-09 16:14:51:700 0x48c7798 OCC::ownCloudGui::slotSyncStateChange: Sync state changed for folder  "ownCloud" :  "Success"
08-09 16:14:51:675 0x63ff5c0 OCC::WatcherThread::watchChanges: void OCC::WatcherThread::watchChanges(size_t, bool*) Found change in "F:/Davis-ownCloud/.owncloudsync.log" action: 3
08-09 16:14:51:708 0x48c7798 OCC::FolderWatcher::pathIsIgnored: * Discarded by component ignore pattern  ".owncloudsync.log"
08-09 16:14:51:902 0x48c7798 OCC::FolderMan::slotFolderSyncFinished: <===================================== sync finished for  "ownCloud"
08-09 16:14:56:044 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_error(QAbstractSocket::SocketError) QAbstractSocket::RemoteHostClosedError QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0 QAbstractSocket::ConnectedState
08-09 16:14:56:045 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0
08-09 16:15:04:705 0x48c7798 OCC::ownCloudGui::slotShowSettings: void OCC::ownCloudGui::slotShowSettings()
08-09 16:15:04:710 0x48c7798 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (The specified procedure could not be found.)
08-09 16:15:04:717 0x48c7798 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001

08-09 16:15:04:718 0x48c7798 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available
08-09 16:15:04:896 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://davis.blaucloud.de" + "/"
08-09 16:15:08:295 0x48c7798 OCC::AbstractNetworkJob::setTimeout: void OCC::AbstractNetworkJob::setTimeout(qint64) 5000
08-09 16:15:08:300 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::LsColJob created for "https://davis.blaucloud.de" + "/"
08-09 16:15:13:334 0x48c7798 OCC::AbstractNetworkJob::slotTimeout: virtual void OCC::AbstractNetworkJob::slotTimeout() OCC::LsColJob(0x7150fb8) Timeout  QUrl( "https://davis.blaucloud.de/remote.php/webdav/" ) 
08-09 16:15:13:336 0x48c7798 OCC::AbstractNetworkJob::slotFinished: void OCC::AbstractNetworkJob::slotFinished() 5 "Operation canceled" QVariant(Invalid)
08-09 16:15:13:339 0x703fe20 unknown: void QHttpNetworkConnectionChannel::close() QSslSocket(0x71f7808) 4 QObject(0x0) 
08-09 16:15:13:340 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x71f7808) QObject(0x0)  0 false 3 16
08-09 16:15:14:114 0x48c7798 OCC::ConnectionValidator::checkAuthentication: # Check whether authenticated propfind works.
08-09 16:15:14:116 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://davis.blaucloud.de" + "/"
08-09 16:15:20:215 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_error(QAbstractSocket::SocketError) QAbstractSocket::RemoteHostClosedError QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0 QAbstractSocket::ConnectedState
08-09 16:15:20:215 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0
08-09 16:15:29:693 0x48c7798 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (The specified procedure could not be found.)
08-09 16:15:29:709 0x48c7798 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001

08-09 16:15:29:709 0x48c7798 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available
08-09 16:15:29:777 0x48c7798 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (The specified procedure could not be found.)
08-09 16:15:29:777 0x48c7798 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001

08-09 16:15:29:793 0x48c7798 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available
08-09 16:15:36:027 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://davis.blaucloud.de" + "/"
08-09 16:15:40:293 0x48c7798 OCC::Folder::slotRunEtagJob: * Trying to check "ownCloud" for changes via ETag check. (time since last sync: 48 s)
08-09 16:15:40:293 0x48c7798 OCC::FolderMan::slotRunOneEtagJob: Scheduling "ownCloud" to check remote ETag
08-09 16:15:40:293 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::RequestEtagJob created for "https://davis.blaucloud.de" + "/"
08-09 16:15:40:871 0x48c7798 OCC::Folder::etagRetreived: * Compare etag with previous etag: last: ""55c72a1683f37""55be52c3b623a""55bcadd88ec27""55c39130e933c""55bb39361bcfd""55bcc026ac18e""55bb4d9eaf70c""9934f8c2b7e86781426b3686ebb409bf""55c71cb514e78""55c38de37226c"" , received: ""55c72a1683f37""55be52c3b623a""55bcadd88ec27""55c39130e933c""55bb39361bcfd""55bcc026ac18e""55bb4d9eaf70c""9934f8c2b7e86781426b3686ebb409bf""55c71cb514e78""55c38de37226c""
08-09 16:15:40:871 0x48c7798 OCC::ownCloudGui::slotComputeOverallSyncStatus: Folder in overallStatus Message:  OCC::Folder(0x640bca0)  with name  "ownCloud"
08-09 16:15:40:902 0x48c7798 OCC::FolderMan::slotRunOneEtagJob: No more remote ETag check jobs to schedule.
08-09 16:15:45:870 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_error(QAbstractSocket::SocketError) QAbstractSocket::RemoteHostClosedError QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0 QAbstractSocket::ConnectedState
08-09 16:15:45:870 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0
08-09 16:15:46:120 0x48c7798 OCC::ConnectionValidator::checkAuthentication: # Check whether authenticated propfind works.
08-09 16:15:46:120 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://davis.blaucloud.de" + "/"
08-09 16:15:52:256 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_error(QAbstractSocket::SocketError) QAbstractSocket::RemoteHostClosedError QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0 QAbstractSocket::ConnectedState
08-09 16:15:52:256 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0
08-09 16:16:07:152 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://davis.blaucloud.de" + "/"
08-09 16:16:10:292 0x48c7798 OCC::Folder::slotRunEtagJob: * Trying to check "ownCloud" for changes via ETag check. (time since last sync: 78 s)
08-09 16:16:10:292 0x48c7798 OCC::FolderMan::slotRunOneEtagJob: Scheduling "ownCloud" to check remote ETag
08-09 16:16:10:292 0x48c7798 OCC::AbstractNetworkJob::start: !!! OCC::RequestEtagJob created for "https://davis.blaucloud.de" + "/"
08-09 16:16:10:855 0x48c7798 OCC::Folder::etagRetreived: * Compare etag with previous etag: last: ""55c72a1683f37""55be52c3b623a""55bcadd88ec27""55c39130e933c""55bb39361bcfd""55bcc026ac18e""55bb4d9eaf70c""9934f8c2b7e86781426b3686ebb409bf""55c71cb514e78""55c38de37226c"" , received: ""55c72a1683f37""55be52c3b623a""55bcadd88ec27""55c39130e933c""55bb39361bcfd""55bcc026ac18e""55bb4d9eaf70c""9934f8c2b7e86781426b3686ebb409bf""55c71cb514e78""55c38de37226c""
08-09 16:16:10:855 0x48c7798 OCC::ownCloudGui::slotComputeOverallSyncStatus: Folder in overallStatus Message:  OCC::Folder(0x640bca0)  with name  "ownCloud"
08-09 16:16:10:871 0x48c7798 OCC::FolderMan::slotRunOneEtagJob: No more remote ETag check jobs to schedule.
08-09 16:16:15:839 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_error(QAbstractSocket::SocketError) QAbstractSocket::RemoteHostClosedError QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0 QAbstractSocket::ConnectedState
08-09 16:16:15:839 0x703fe20 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x71f7808) QObject(0x0)  0 false 3 0
ogoffart commented 9 years ago 
08-09 16:15:13:334 0x48c7798 OCC::AbstractNetworkJob::slotTimeout: virtual void OCC::AbstractNetworkJob::slotTimeout() OCC::LsColJob(0x7150fb8) Timeout  QUrl( "https://davis.blaucloud.de/remote.php/webdav/" )

Looks like the server did not reply to the PROPFIND that should return the list of folders.

We should probably show to the user some feedback like a "Failed to fetch list of folder" item or something.

phil-davis commented 9 years ago

That is a commercially hosted server running 8.0. The symptoms always happen as soon as I add any External Storage and share it to a user. They immediately cannot open/refresh the client-end folders to sync tree. Is there some general problem here between client 2.0.* and server 8.0? Or is there some issue with the configuration of the server itself? I will try again with client 1.8.4 and make sure it works OK from there - that will confirm that the server is responding to "1.8.4"-style requests. Then it will be a matter of working out what the 2.0 client is doing a bit different.

jancborchardt commented 9 years ago

Oh also, if there are new folders which are too big, then the selective sync tree should be expanded by default (and scrolled to the respective folders) to make them visible.

guruz commented 9 years ago

The symptoms always happen as soon as I add any External Storage and share it to a user.

Which type of external storage @phil-davis ?

Oh also, if there are new folders which are too big, then the selective sync tree should be expanded by default (and scrolled to the respective folders) to make them visible.

Afaik this had been done, @ogoffart ?

phil-davis commented 9 years ago

I add ownCloud external storage that accesses a folder on another ownCloud at the same blaucloud.de and running the same 8.0 hosted server software. I can add the external storage even as an ordinary unpriv user, so it is just my own external storage - no fancy system-wide stuff or... I expect that this would be easy to reproduce in a lab.

phil-davis commented 9 years ago

I just created myself a User1@myfamily.blaucloud.de (8.0) I added the account to my multi-account client. It downloads the basic Documents and Pictures folders. The folders to sync tree expands fine. Using the web interface logged in as User1 I created an external storage to ownCloud my.name@myorg.blaucloud.de folder testshare (8.0) The files can all be seen fine in the server webUI by User1. Go back to the multi-account client and try to expand the folders to sync tree - nothing comes.

phil-davis commented 9 years ago

I installed ownCloud client 1.8.4 on another Windows7 computer. I connected it to the same User1@myfamily.blaucloud.de account on the same ownCloud server. It downloaded all the files, including those in testshare. When I click "Choose What to Sync" it is "Loading..." for a moment and then the folder tree is displayed. So 2.0 definitely has a regression compared to 1.8.4 in this scenario.

guruz commented 9 years ago

@PVince81 Can this in any way be related to (missing) https://github.com/owncloud/core/issues/13882 ? But then why would @phil-davis have no problem with 1.8.4 but have a problem with 2.0?

@ogoffart My guess is that it is related to the WebDAV properties possibly having changed with 2.0? Although in folderstatusmodel.cpp I see job->setProperties(QList<QByteArray>() << "resourcetype" << "quota-used-bytes"); which i don't see in SelectiveSyncTreeView::slotItemExpanded

guruz commented 9 years ago

@phil-davis ^^ those commits should be in rc1

phil-davis commented 9 years ago

I will download that now from: https://owncloud.org/install/#testing-development Note that there is text on that page that still says: Desktop Clients 2.0.0 beta1 But it looks like the link will download RC1.

phil-davis commented 9 years ago

Also the test-pilot links look a bit mixed up at https://owncloud.org/install/#testing-development Both ordinary and testpilot links for Windows point to the same place. Mac looks OK Linux seems to be opposite

danimo commented 9 years ago

@phil-davis

Desktop Clients 2.0.0 beta1 But it looks like the link will download RC1.

Fixed. Thanks.

phil-davis commented 9 years ago

Version 2.0.0rc1 (build 5407) The new error reporting code works: ownclouderrorloadinglistoffolders So now I get some feedback that there is a problem.

jancborchardt commented 9 years ago

@ogoffart @guruz can we have the text non-italic please? Instead make it half-grey. We should not have italic text anywhere in the app.

danimo commented 9 years ago

@jancborchardt The reason is that "half-grey" does not work as a color specifier. We must not hard code colors. Ever. We can of course use color roles from the palette that will usually map to a grey tone. Otherwise we'll end up in the same messy situation as in #3582.

Proposal

  1. Map <i> to a palette color through CSS (labels in Qt use CSS 2.0 for simple styling)
  2. Ensure a refresh of the CSS values for theme, if a theme or style change events happen (see changeEvent() impl in 379beb268f53fc7b64196202d0dfa3b0d14f607f for details). Otherwise, a dynamic change of themes during the app runtime will require an app restart.
jancborchardt commented 9 years ago

Ok, does 50% transparency work then?

phil-davis commented 9 years ago

While we are fussing around the UI of this error message: s/list of folder/list of folders/

phil-davis commented 9 years ago

Note: During the account setup wizard, I can click "choose folders to sync" and the folder list is displayed, even for an account that has this problem. So that initial "choose folders to sync" dialog (which looks just like the old 1.8.4 interface) is working. That might give a clue or place to compare the difference in what the code is doing.

ckamm commented 9 years ago

@phil-davis How long does the "choose folders to sync" dialog need to fetch the folder list? The main difference I see is that the folder status model has an explicit five-second timeout...

phil-davis commented 9 years ago

I quit the ownCloud client. Then start it again (so that every account has no cached folder list any more). When I drop down each folder list for each "normal" account there is a slight but noticeable delay (up to maybe 1 second) and then the folder list displays. For the "User1" that has the external storage it is clearly much longer (about the 5 seconds you mentioned) and then the "Error while loading..." message is displayed. It is repeatable, and any account with external storage always has the problem.

phil-davis commented 9 years ago

Can anyone else replicate this issue?

guruz commented 9 years ago

Note that client 1.8.4 can display the folders to sync even when there is External Storage. So I guess there is a regression here somewhere in the way all that was enhanced for multi-account.

That's why I was thinking it is related to the WebDAV properties used...

Although it's still a server annoyance if it takes so long (CC @PVince81 )

ckamm commented 9 years ago

@phil-davis Thanks for checking. How long does it take to populate the folder list in the ""choose folders to sync" part of the setup wizard for an affected account? (I'll try to reproduce now)

PVince81 commented 9 years ago

Please raise a separate issue for the performance issue. If this is an initial PROPFIND, it might be the computation of folder sizes that is taking long. The second PROPFIND shouldn't take that long.

phil-davis commented 9 years ago

I am in western Nepal - everything takes a long time. The delay for the "normal" accounts to open the folder list is fine, it is the normal delay for a round-trip (or 2) from Nepal to Germany.

phil-davis commented 9 years ago

@ckamm The delay to populate the folder list during the setup wizard is the same as for the other populates on startup for the other accounts that work. So that all seems good and consistent.

ckamm commented 9 years ago

@phil-davis I couldn't reproduce it this way:

The cross-server share shows up with the correct size in that view. I was using blaucloud and another server to test with. Do you have an idea of what might be wrong? Can you give me credentials to a dummy account where I can reproduce this? Feel free to email me at mail@ckamm.de.

phil-davis commented 9 years ago

@ckamm Email sent with logon details to "User1" account that demonstrates the problem.

phil-davis commented 9 years ago

owncloudzzz Version 2.0.0-nightly20150820 (build 5412) Error message text is now correct and not in italics.

ckamm commented 9 years ago

@phil-davis Thank you! With your setup I can reproduce the problem. For me the setup-wizard folder list takes around 66s to load and the account settings folder list aborts after 5s. What we need is

phil-davis commented 9 years ago

I am very surprised about the times taken to access a federated share between 2 ownClouds that are are hosted with the same provider, and the federated share only contains a very small amount of test files. I wonder how people use federated shares in real life? Or is it much better on 8.1? or? Maybe a way to help the client for now is:

a) When the client sends the request for folder list to the server, put up a message: "Waiting to receive folder list" (if it is reasonably easy to do - only put the message up after 1 second of no response from server - that will avoid having a message that flashes there for a short number of milliseconds and is replaced by the folder list)

b) Increase the timeout to some long time - 120 seconds?

At least users will know that something happened when they clicked to open the folder list. Some note can be put in release notes or documentation that mentions "Waiting to receive folder list" and explains that there is a possible back-end time delay issue. Users can easily do a web search of "Waiting to receive folder list" and will find an explanation - which might reduce the rate of related support threads on the forum...

ckamm commented 9 years ago

We'll add progress indication and a longer timeout in the next version.

mscansian commented 9 years ago

I'm having the same issue. I currently have 2 external storages AWS S3 and DreamObjects (which also uses S3 protocol). The first time I log in in the desktop client, it takes around 1 minute to show what folders to sync, but it does!

On the other hand, if I click in the Sync message to show folders it just timeouts in around 5 secs and shows me "Error while loading the list of folders from the server"

Wish I could be of more help, but I'm quite illiterate in C++. The least I can do is provide my log file:

Version: 2.0.1

09-17 23:50:12:481 0xcd5300 void OCC::AbstractNetworkJob::setTimeout(qint64) 5000 
09-17 23:50:12:482 0xcd5300 !!! OCC::LsColJob created for "http://drpexe.com" + "/" 
09-17 23:50:16:531 0xcd5300 # Check whether authenticated propfind works. 
09-17 23:50:16:532 0xcd5300 !!! OCC::PropfindJob created for "http://drpexe.com" + "/" 
09-17 23:50:17:722 0xcd5300 virtual void OCC::AbstractNetworkJob::slotTimeout() OCC::LsColJob(0x13c35f0) Timeout  QUrl( "http://drpexe.com/remote.php/webdav/" )  
09-17 23:50:17:723 0xcd5300 void OCC::AbstractNetworkJob::slotFinished() 5 "Operation canceled" QVariant(, ) 
09-17 23:50:17:726 0xcd5300 void OCC::AbstractNetworkJob::setTimeout(qint64) 5000 
09-17 23:50:17:727 0xcd5300 !!! OCC::LsColJob created for "http://drpexe.com" + "/" 
09-17 23:50:19:604 0xcd5300 !!! OCC::PropfindJob created for "http://drpexe.com" + "/" 
09-17 23:50:22:828 0xcd5300 virtual void OCC::AbstractNetworkJob::slotTimeout() OCC::LsColJob(0x13dcbc0) Timeout  QUrl( "http://drpexe.com/remote.php/webdav/" )  
09-17 23:50:22:829 0xcd5300 void OCC::AbstractNetworkJob::slotFinished() 5 "Operation canceled" QVariant(, ) 
09-17 23:50:38:253 0xcd5300 * Trying to check "ownCloud" for changes via ETag check. (time since last sync: 32 s) 
09-17 23:50:38:254 0xcd5300 Scheduling "ownCloud" to check remote ETag 
09-17 23:50:38:255 0xcd5300 !!! OCC::RequestEtagJob created for "http://drpexe.com" + "/" 
09-17 23:50:48:531 0xcd5300 # Check whether authenticated propfind works. 
09-17 23:50:48:532 0xcd5300 !!! OCC::PropfindJob created for "http://drpexe.com" + "/" 
09-17 23:50:51:729 0xcd5300 * Compare etag with previous etag: last: ""55fb7b3a37272""55e477311bd07""55e476e8b4bf1""55e4b2ef0e500""55fb7ad87a0de""55fb7ae703bfd"" , received: ""55fb7bf8a4184""55e477311bd07""55e476e8b4bf1""55e4b2ef0e500""55fb7beab8697""55fb7beaefed4"" 
09-17 23:50:51:729 0xcd5300 Folder in overallStatus Message:  OCC::Folder(0xf56f90)  with name  "ownCloud"
phil-davis commented 9 years ago

I think that the "choose what to sync" dialog in the initial setup wizard does not have a timeout (or at least has a very long timeout) because that works if you wait long enough.

ckamm commented 8 years ago

You now get a progress indication after 1s of waiting. The timeout is increased from 5s to 60s.

phil-davis commented 8 years ago

Thanks, I will try with the nightly that will build tonight and report back... It seems that new code is in master. The nightly builds are of 2.0 branch: Version 2.0.2-nightly20151015 (build 5542) I am not really in a position to set up my own build environment, so I can't test this just yet.

chesterdkat commented 8 years ago

FYI, I had the same issue on OS X 10.10 as well as 10.11. I uninstalled 2.0.1 and reverted to 1.8.4 and the list of folders now shows up again.

I was also advised to try 2.0.2-nightly20151008 (build 2772) which did not fix the problem. Only going back to 1.8.4 fixed this issue for me.

phil-davis commented 8 years ago

The increase of the timeout to 60 seconds was added to 2.0 branch and so is now in the 2.0.2 nightly build - good. My test user setup on blaucloud.de is responding faster than it used to. I think it has been upgraded from 8.0.* to 8.1.1 since the last time I tested this. It seems that the performance of external connections is much better in server 8.1.1. So I had to make 3 external storage connections to reliably get the response to opening the folder sync tree to exceed 5 seconds. I did that and checked with an old client version that I got the timeout error. Now with Version 2.0.2-nightly20151016 (build 5546) it waits longer and succeeds, in my test case the response is now taking about 8 seconds to come - looks good. Note: There is extra code in master branch for 2.1 that will display a "waiting" message while waiting for the folder sync tree response. That is not in 2.0, so in 2.0.2 the screen appears to do nothing for a while, and then the folder sync tree appears.