https://bugs.kde.org/show_bug.cgi?id=459980
Fabian Vogt <fab...@ritter-vogt.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|general |general
Assignee|a.saout...@gmail.com |kio-bugs-n...@kde.org
CC| |kdelibs-b...@kde.org
Product|kiofuse |frameworks-kio
Summary|kio-fuse sometimes stops |setTimeoutSpecialCommand
|operating for single client |breaks FileJob
Version|5.0.1 |git master
--- Comment #6 from Fabian Vogt <fab...@ritter-vogt.de> ---
That's actually much easier to reproduce than I expected, I can trivially
repeat it here.
To debug it, I added some code to log all KIO slave commands. That showed that
CMD_CLOSE was actually sent twice to the slave, which turned out to be a bug in
KIO: https://invent.kde.org/frameworks/kio/-/merge_requests/1013
That's unrelated though and (in this case at least) harmless.
I found the root cause a bit later. The sftp ioslave calls
setTimeoutSpecialCommand, which means that SFTPWorker::special is called in
regular intervals from the dispatching loop. After the sftp slave was ported
from SlaveBase to WorkerBase, it now calls finished(), which resets the slave
and returns it to the pool. For FileJob this is fatal, as the state is lost and
all the application gets is a successful (!) code from the finished() signal!
FWICT the right way here is to change WorkerSlaveBaseBridge::special from using
finalize(base->special(data)); to maybeError(base->special(data)); and revert
4747517737dcfbfa1964ef818908a69067b7936b.
--
You are receiving this mail because:
You are watching all bug changes.
