GNOME Bugzilla – Bug 598092
gvfsd can time out enumerating long directories
Last modified: 2014-01-23 08:21:48 UTC
When accessing a folder on my phone over bluetooth about 80% of the time it will fail with this message: The folder contents could not be displayed. Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. The folder is quite large, about 120 items. Accessing the folder may work 1 out of 5 times with gvfs, however, using obexftp from the command line works everytime. Is there a way to extend the timeout for gvfs when accessing such a folder or some other solution?
There's 2 problems here, one is that obex-data-server takes too long to tell us the directory listing, this should be fixed in bug 609340. The other problem is that there's no way in gvfs to ping back gvfsd to tell it, "I know I'm taking a while, but something's happening". It should be possible to report progress during an enumeration (currently obexftp would need the full listing before parsing it, but it could tell the front-end "I'm still receiving data").
Dbus methods now have infinite timeouts which means that this has been fixed.
Reopening since the enumerate dbus callbacks don't seem to have infinite timeouts which means that it is possible to have timeouts on large directories.
Created attachment 264407 [details] [review] daemon: Set infinite timeout for enumerate response Set an infinite timeout for responses to enumerate() otherwise it can timeout when enumerating large, slow directories.
Review of attachment 264407 [details] [review]: Looks good, thanks!
Pushed to master as 31129df and stable as 62cadd5. Thanks!