SUMMARY If an audio CD is scratchy, reading anything out of it can take hours. The application making the request to open a wav file over an audio track will hang indefinitely. STEPS TO REPRODUCE 1. Mount a scratchy audio CD. 2. Tell Picard to open a track. OBSERVED RESULT The disc drive is trying to read the track. Picard hangs. EXPECTED RESULT Let the fuse controller fail with an input error. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Tumbleweed 20221231 (available in About System) KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION Of course, in an ideal world, everything would be async in the client and nothing would hang. I am afraid we are still far from that dream state.
kio-fuse could in theory set a timeout for certain requests, but it's hard to say what the timeout should be. Some requests should finish in <30s but some protocols (especially over network) can take longer. It's also not great to just report -ETIMEDOUT or even -EIO to applications, they're probably going to fail with an unnot helpful error message, just retry or worse, ignore the error... There's https://invent.kde.org/system/kio-fuse/-/merge_requests/56, which should make this more user friendly. With that, KIO jobs which take longer (>2s currently) are shown in Plasma and it's possible to cancel them. IMO in this particular case the audiocd:/ protocol could handle the timeout itself.
(In reply to Fabian Vogt from comment #1) > IMO in this particular case the audiocd:/ protocol could handle the timeout > itself. The audiocd slave sort of can handle this because you can set the paranoia parameter to a lower value. But it is hardly discoverable and you have to unmount. I cannot imagine us telling a non-nerdy user to do that each time. By the time something hangs, it is already too late :-(
(In reply to Christopher Yeleighton from comment #2) > (In reply to Fabian Vogt from comment #1) > > > IMO in this particular case the audiocd:/ protocol could handle the timeout > > itself. > > The audiocd slave sort of can handle this because you can set the paranoia > parameter to a lower value. But it is hardly discoverable and you have to > unmount. I cannot imagine us telling a non-nerdy user to do that each time. > By the time something hangs, it is already too late :-( Hm, maybe just use a better default value in kio_audiocd?
(In reply to Fabian Vogt from comment #3) > Hm, maybe just use a better default value in kio_audiocd? This is a good idea in itself but we need to be safe and we want our users to feel safe. We cannot foresee any possible SNAFU in every possible slave. We need a safety switch, audio CD being only an example of what can happen.