Bug 463754

Summary:	no timeout for the slave
Product:	[Frameworks and Libraries] kiofuse	Reporter:	Christopher Yeleighton <giecrilj>
Component:	general	Assignee:	a.saoutkin
Status:	REPORTED ---
Severity:	normal	CC:	aspotashev, fabian, kio-bugs-null
Priority:	NOR
Version First Reported In:	5.0.1
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=291947
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Christopher Yeleighton 2023-01-02 22:27:11 UTC

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.

Comment 1 Fabian Vogt 2023-01-02 22:42:57 UTC

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.

Comment 2 Christopher Yeleighton 2023-01-02 23:22:46 UTC

(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 :-(

Comment 3 Fabian Vogt 2023-01-03 00:53:51 UTC

(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?

Comment 4 Christopher Yeleighton 2023-01-03 04:12:39 UTC

(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.