https://bugs.kde.org/show_bug.cgi?id=452729
--- Comment #9 from Harald Sitter <sit...@kde.org> --- All of this makes sense but I don't think any of these actually hit the heart of this bug. I've done some more debugging to understand this problem better and stumbled upon https://invent.kde.org/frameworks/kio/-/blob/6b1fd98193e08b22dbf77e9e33606b2b1800ef88/src/core/mimetypefinderjob.cpp#L249 which is actually why this is broken to begin with. What happens is that the worker sends the mimetype, then a blocking emit chain ends up in the aformentioned suspension and by the time the emit chain unwinds and we reach https://invent.kde.org/frameworks/kio/-/blob/6b1fd98193e08b22dbf77e9e33606b2b1800ef88/src/core/slaveinterface.cpp#L252 the connection is in suspended state and the worker gets no reply, leaving it hanging on https://invent.kde.org/frameworks/kio/-/blob/6b1fd98193e08b22dbf77e9e33606b2b1800ef88/src/core/slavebase.cpp#L707 and retaining the open file (lock). That is: this is actually a variant of bug #434455 but less obvious because we hold a remote busy. This seems flawed on a fundamental level though: we basically block the worker on waiting for something that never happens. We may as well abort it and start from scratch. With that in mind your suggestion for using open&read in the mimetypefinder is actually the best solution. I suspect this is implemented the way it is because not all workers implement open&read though, so we still need a solution for when that is the case. A trivial approach might be to abort the worker as a whole? i.e. - try open() - on failure: use get - else: read() - get() - receive mimetype - send ::kill() to the worker get() is a sledgehammer way of getting the mimetype, so it seems only right that we also use the sledgehammer way of stopping it -- You are receiving this mail because: You are watching all bug changes.
