When trying to list available/discovered hosts in /run/user/<uid>/kio-fuse-*/smb/, listing hangs indefinitely. STEPS TO REPRODUCE 1. cd /run/user/1000/kio-fuse-*/smb 2. ls OBSERVED RESULT "ls" process hangs, never returns Listing the shares of a host, e.g. "ls /run/user/1000/kio-fuse-*/smb/hostname.local/", works without excessive delays. EXPECTED RESULT ls shows the same hosts as Dolphin when browsing "smb://" Likely related, Dolphin shows the "Loading folder..." progress indicator indefinitely. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20210429 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
> Likely related, Dolphin shows the "Loading folder..." progress indicator indefinitely. If Dolphin is hanging, KIO FUSE is guaranteed to hang. Sounds like an issue in Samba's KIO::listDir implementation.
Yep, I can reproduce the issue even with "QT_LOGGING_RULES=*.debug=true KDE_FORK_SLAVES=true kioclient5 ls smb://". It shows that the WSDiscoverer never finishes. This is because of this in smb/wsdiscoverer.cpp: // NB: only started after first match! If we have no matches the slave will // stop us eventually anyway. Doing m_probeMatchTimer.start(); in WSDiscoverer::start fixes the issue.
There was a global timeout for all discoverers but that was eventually removed because it broke smbc listing - implemented as discovery - WSD never got a timeout after that. the spec does say there should be a timeout though, need to read up on the details https://bugs.kde.org/show_bug.cgi?id=430947#c20
A possibly relevant merge request was started @ https://invent.kde.org/network/kio-extras/-/merge_requests/121
Git commit bef55f100bfb14b0d33d7e88c29b261bd959b089 by Harald Sitter. Committed on 22/09/2021 at 09:12. Pushed by sitter into branch 'master'. implement timeouts from ws-discovery previously we had a global timeout in smb_browse but that was eventually removed to not break SMBC discovery, which is also used for listing directories. this left WSD without any timeout system when no WSD hosts are on the network because the internal timeout tracking would only start after the first response. instead implement the actually specified timeout mechanics of WSD. - /Probe may only be Matched within MATCH_TIMEOUT (m_probeMatchTimer = global timeout tracker now) - /Resolve may only be Matched within MATCH_TIMEOUT (encapsulated inside new WSDResolver) - PBSD may only be answered within HTTP_TIMEOUT (couldn't find a specified timeout so I'm guessing one would ordinarily use a default http timeout, since we only do a single cheap query I'm using a more opinionate timeout though) MATCH_TIMEOUT is derived form the DPWS spec rather than the underlying ws-discovery because it has more lenient timing and is generally a bit more assertive with requirements. M +101 -23 smb/wsdiscoverer.cpp M +7 -1 smb/wsdiscoverer.h https://invent.kde.org/network/kio-extras/commit/bef55f100bfb14b0d33d7e88c29b261bd959b089