Until now I had never experienced this problem, but since upgrading to KDE 4.11.2 (both OpenSUSE and Kubuntu), when I use the "Extract here" option from the context menu in Dolphin, when you right click on a compressed file, it seems that trying to do the extraction but it never happens. Moreover, the Ark process remains running in the background. To decompress, I am forced to open the Ark window. Reproducible: Always Steps to Reproduce: 1. Using KDE 4.11.2, trying to decompress a compressed file from Dolphin, using the "Extract here" option from the context menu. Actual Results: Ark does not extract the content of compressed files using the context menu in Dolphin. The Ark process remains running in the background. Expected Results: Ark should extract the content of compressed files directly using the option "Extract here" from the context menu in Dolphin.
I don't understand why the severity has been changed to normal, because, as I said, the Ark process remains hanged in the background. And your severity policy say that when a program hangs or crash, the severity level is CRASH.
From how I understand the description, the issue does not occur, when using ark directly?
The issue occurs when you try to decompress a compressed file from Dolphin, right-clicking and selecting "Extract Here" in the context menu.
I can confirm this bug. I'm on Arch Linux (Kernel Linux san 3.12.4-1-ck #1 SMP PREEMPT Mon Dec 9 01:18:07 CET 2013 x86_64 GNU/Linux) having Version 4.11.4-1 of KDE installed. Same behaviour as in the original bug description, though i some additional detail: Using ark directly gives the expected results. If i start dolphin via the kde menu or from a starter (aka via the gui) and try to unpack anything via the context menu, the bug appears. The ark process just remains running having been called from the dolphin process which shows up as kdeinit4: dolphin [kdeinit] --icon system-file-manager -captio |_/usr/bin/ark/ --batch --autodestination --autosubfolder FILENAME |_zipinfo |_QProcessManager |_QThread Of these zipinfo does show up as a zombie process. As i tried to gather debug information by starting dolphin via the command line, the bug does not appear. Unpacking via the context menu worked as expected and the zipinfo process either didn't show up or was to fast to be seen. Instead i got a normal unzip process. So how can i gather debug information for you guys without using the terminal?
Can confirm openSUSE 13.1 x86/64 KDE 4.11.4 All context options for decompressing do not work. In a terminal I see the following if I try: $ /usr/bin/ark --batch --autodestination --dialog ./0815.zip Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath) ark(11686) KSambaSharePrivate::testparmParamValue: We got some errors while running testparm "Load smb config files from /etc/samba/smb.conf Loaded services file OK. ERROR: pid directory /var/run/samba does not exist " Don't know if this could be useful. Regards Regi
Bug confirmed on KDE 4.11.4: 1) start dolphin 2) right click on .zip file 3) select "extract here"
Could someone attach an archive that shows this problem? I've tried both "ark --batch --autodestination" directly and using Dolphin's context menu and choosing Extract->Extract Archive Here with a few different tarballs and zip files and everything worked as expected, on both KDE from git master on FreeBSD and ArchLinux's standard 4.12.0 packages.
(In reply to comment #7) > Could someone attach an archive that shows this problem? I've tried both > "ark --batch --autodestination" directly and using Dolphin's context menu > and choosing Extract->Extract Archive Here with a few different tarballs and > zip files and everything worked as expected, on both KDE from git master on > FreeBSD and ArchLinux's standard 4.12.0 packages. I recently updated to KDE 4.12.0 on openSUSE 13.1. I can confirm that "Extract->Extract Archive Here" work, as long as there is no dialog involved, like it would be if some or all files of the archive already exists. Simply try to extract an archive twice in the same place. If I choose "Extract->Extract Archive To..." then the file dialog pops up but do not response for a long time. Same if I choose "Compress->Compress To...". It seems that in all actions where a dialog is involved the process hangs for a longer time. After approx. 5-10 Minutes now the dialog pops up - which is a change to KDE 4.11.4 where the dialog never popped up. Hope this information helps. Merry Christmas Regi
Created attachment 84263 [details] Test tarball with two screenshots Attachment to my comment https://bugs.kde.org/show_bug.cgi?id=328120#c8
Hmm, all those use cases still work fine here (git master and 4.12.0). From what I understood, right now it's not the extraction or compression process that seems to be hanging, but rather the dialog that's taking an awfully long time to be shown? A few more questions then: * Do you have any network shares or anything that could be causing this slow I/O that's shown in the Places section of the file dialogs? * Do you experience this kind of slowness when opening file dialogs in other programs as well? * What if you launch Ark as a standalone program and try to create or extract archives from it?
(In reply to comment #10) > Hmm, all those use cases still work fine here (git master and 4.12.0). > > From what I understood, right now it's not the extraction or compression > process that seems to be hanging, but rather the dialog that's taking an > awfully long time to be shown? Right - at least in KDE 4.12.0. > A few more questions then: > * Do you have any network shares or anything that could be causing this slow > I/O that's shown in the Places section of the file dialogs? I have a NFSv4-Share, mounted with autofs. I disabled this already, without any changes in the slow dialogs. The local fs is EXT4. The root partition is on a SSD, while home and tmp are mounted from separate HDD partitions. > * Do you experience this kind of slowness when opening file dialogs in other > programs as well? No - KDE (Qt) and GTK applications work fine. > * What if you launch Ark as a standalone program and try to create or > extract archives from it? This works fine, only if I use the context menu from Dolphin causes problems.
I updated to KDE 4.12.0 recently and for now, the bug did not appear on my systems anymore.
(In reply to comment #10) Hmm - this is strange, I just received some updates for openSUSE 13.1. There where no direct dependencies to ARK (as far as i could see), but I think some of them has indirect impact: aaa_base, aaa_base-extras, bluedevil, kio_iso and some downgrades as well: kdebase4-session, NetworkManager-kde4 Now it works fine :-) No problems for me any more :-))
Good to hear. I'll give the others who have commented here some more time to check if the bug is also gone for them before closing the report.
After the latest update to KDE 4.12.0 I'm not able to reproduce the bug anymore.
Right, I guess we have enough quorum to close the report.