Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
phil-davis opened this issue Jul 31, 2015 · 59 comments
Assignees
Milestone

Comments

@phil-davis
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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

Tested the similar setup here, works nicely.

@jancborchardt
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@phil-davis
Copy link
Contributor Author

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
Copy link
Contributor

ogoffart commented Aug 5, 2015

@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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor

guruz commented Aug 17, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

guruz commented Aug 18, 2015

@PVince81 Can this in any way be related to (missing) owncloud/core#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

@dragotin dragotin assigned ckamm and unassigned ogoffart Sep 10, 2015
@ckamm ckamm modified the milestones: 2.1-next, 2.0.2-next Sep 15, 2015
@mscansian
Copy link

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
Copy link
Contributor Author

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 added a commit to ckamm/owncloud-client that referenced this issue Oct 14, 2015
We now show 'Fetching data...' after a second.

This also increased the timeout to 60s, making the error
condition much less likely.
ckamm added a commit that referenced this issue Oct 14, 2015
We now show 'Fetching data...' after a second.

This also increased the timeout to 60s, making the error
condition much less likely.
@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Oct 14, 2015
@ckamm
Copy link
Contributor

ckamm commented Oct 14, 2015

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

@phil-davis
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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.

@guruz
Copy link
Contributor

guruz commented Oct 16, 2015

@phil-davis Thanks for testing 2.0 :)
I'll keep this open for now until someone also tested the 2.1 code..

@Dianafg76
Copy link

I tested this issue and on Desktop v ownCloud-2.1.0.5586-nightly20151028-setup.exe it is working the same that v 2.0.2

But whe the account is sync, on the Folder Dropbox you can see the message "Fetching folder list from server ...."

screen shot 2015-10-28 at 15 49 32

screen shot 2015-10-28 at 15 49 44

@phil-davis
Copy link
Contributor Author

For me, it shows "Fetching folder list from server..." when opening the whole folder sync tree view, and when opening sub-folders in the tree. But each time, when the server reply is received, the message "Fetching folder list from server..." goes away and the tree is displayed nicely.
That is the expected behavior.
@Dianafg76 How did you get the message to be "stuck" on the display?

@Dianafg76 Dianafg76 removed the ReadyToTest QA, please validate the fix/enhancement label Oct 28, 2015
@guruz
Copy link
Contributor

guruz commented Nov 3, 2015

@Dianafg76 Can you re-test and wait longer?

@Dianafg76
Copy link

But now when you sync the folder Dropbox, the total B is 0 and is not true
screen shot 2015-11-04 at 09 23 48

Desktop v ownCloud-2.1.0.2851-nightly20151104.pkg
Server v {"installed":true,"maintenance":false,"version":"8.1.4.0","versionstring":"8.1.4 RC1","edition":""}

@guruz
Copy link
Contributor

guruz commented Nov 4, 2015

@Dianafg76 Can you create an issue in core for the wrong dropbox size and assign to @icewind1991 ?
There is possibly one already

@phil-davis
Copy link
Contributor Author

As far as I am concerned, the issue here about the folders to sync tree view not opening has been resolved by:

  1. Adding a progress message on the client UI.
  2. Increasing the timeout so the client waits longer.
  3. Apparent improvements in the server response time between server 8.0.* (which my hosted server was on when I first reported) and server 8.1.* (which it is running now) to the PROPFIND when there are external storages.

As @guruz says, the (0 B) folder sizes on the display are a separate issue.

@guruz guruz added the ReadyToTest QA, please validate the fix/enhancement label Nov 4, 2015
@guruz
Copy link
Contributor

guruz commented Nov 4, 2015

👍

@guruz guruz closed this as completed Nov 4, 2015
@Dianafg76
Copy link

OK

@Dianafg76 Dianafg76 added approved by QA and removed ReadyToTest QA, please validate the fix/enhancement labels Nov 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests