Bug 328120

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.