Bug 432298

Summary:	kate will hold the device busy while the file had closed before on this device
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	Zhonghua <kipade>
Component:	general	Assignee:	KIO Bugs <kio-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	a.samirh78, christoph, kdelibs-bugs
Priority:	NOR
Version:	5.78.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Zhonghua 2021-01-30 05:35:20 UTC

SUMMARY


STEPS TO REPRODUCE
1. make sure kate is not running
2. open a file from a removable device with kate(select open with kate in dolphin's context menu, then kate will launch)
3. close the file using kate's tab view
4. try to eject the removable device in dolphin's device tree view

OBSERVED RESULT
dolphin will say some applications like kate,bash are using the device and fail to eject the device.

EXPECTED RESULT
I think the device should be ejected as normal(launch kate first, and follow 2,3,4 steps above, then the device would be ejected successfully)

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Arch Linux 64bit
(available in About System)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION

Comment 1 Dominik Haumann 2021-02-02 02:31:01 UTC

What plugins do you use? Projects plugin? LSP plugin? Does it work when you disable plugins and restart Kate?

Comment 2 flan_suse 2021-03-29 18:26:25 UTC

I don't think this is a bug with Kate. I *strongly* believe this is a bug with KIO or something Dolphin-related.

I can 100% reproduce this with:
* Kate
* XnViewMP
* Chromium browser

If I double-click a text file, image file, or HTML file, and it opens in Kate, XnViewMP, or Chromium, then I close said application, there will be a hanging "file.so" process that prevents me from unmounting an external drive or disconnecting a network share. "Target is busy!"

Once I kill "file.so", I can safely eject the drive or disconnect the share.

Fully updated Manjaro KDE. This recently started after a bunch of KDE updates. I do not have access to the computer until later, where I can provide more information if needed.

Now what makes this interesting is this does *NOT* happen if I first open up XnViewMP, for example, and then click-and-drag a file into the application. Closing the application does not leave a hanging "file.so" process.

Comment 3 Christoph Cullmann 2021-04-04 19:16:45 UTC

Perhaps @dfaure has some insights here.

Comment 4 Ahmad Samir 2022-05-16 15:57:06 UTC

Looks like bug 434455. Marking as such, if you still see this issue feel free to reopen this report.

*** This bug has been marked as a duplicate of bug 434455 ***