Version: (using KDE KDE 3.5.6) Installed from: Ubuntu Packages OS: Linux Hi, I recently came across this bug and a possible solution for it. When I open a .tar.gz archive with a complex directory structure within it using ark and try to extract the contents I get two different behaviors based on how I perform it. 1. If I do not select any of the files inside the archive and click on extract button on the toolbar to extract, it does not give any problem. 2. However, if I select the top-most directory and click on extract button on the toolbar to extract, it gives an error message but the files are extracted properly. I've found where the problem lies. The problem is caused due to the fact that the tar program reports error when both a directory and its files/subdirs are provided in the list of files to be extracted. Consider the following directory structure inside the archive (test.tar.gz). test | |-demo | |-index.html Now executing the following command, tar -xzf test.tar.gz test test/demo test/demo/index.html would generate the following error, tar: test/demo: Not found in archive tar: test/demo/index.html: Not found in archive tar: Error exit delayed from previous errors This is exactly the problem generated by ark. There is no necessity to include the children of the directory selected to be included in the list of files to be extracted, as the contents of the directories specified get extracted by default. tar -xzf test.tar.gz test would be sufficient. However, this is not true for other archive programs like zip. The problem at hand: In the source code of ark, the "FileListView" class (inside filelistview.cpp) contains the function "selectedFilenames()" which adds the children of the selected directory also to the list of selected files. This when used by "TarArch::unarchFileInternal()", causes the problem. Solution: This problem can be solved, if a piece of code is incorporated into "FileListView::selectedFilenames()" to check the mime-type of the currently opened archive and if it is a tar type, the children of the selected directories should not be included in the list of selected files. I hope this understanding would greatly help the developers in fixing the problem soon. I'm very sorry that I'm not able to solve the problem myself as I don't have the time to do fix it in the code.
*** This bug has been confirmed by popular vote. ***
Maybe this is the wrong place to report this, but when i try to extract the latest Firefox release, ark spits errors at me instead of extracted files. I selected the top folder ("firefox") which holds all other files and folders. $ ark /home/cees/software/firefox-3.0a7pre.en-US.linux-i686.tar.bz2 kio (KMimeType): WARNING: mimetype not valid '' (missing entry in the file ?) kio (KMimeType): WARNING: mimetype not valid '' (missing entry in the file ?) kparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found : [KPushButton pointer (0x816a5c0) to widget CancelButton, geometry=100x30+0+0] $ kparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found : [KPushButton pointer (0x816a5c0) to widget CancelButton, geometry=100x30+0+0] kparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found : [KPushButton pointer (0x816a5c0) to widget CancelButton, geometry=100x30+0+0] kparts: WARNING: StatusBarExtension::removeStatusBarItem. Widget not found : [KPushButton pointer (0x816a5c0) to widget CancelButton, geometry=100x30+0+0]
My bad. It did extract files, even though it stated that the extraction operation failed. (tar bitching about files not found in archive) When i extract without selecting the top folder. Everything goes fine. Comparing the file output with KDiff3, i see 0 differences.
That is exactly the problem I had. I hope a fix is released soon.
Why is it taking such a long time to fix this bug? Will fixing this affect any other part of KDE? I hope this bug does not percolate into KDE 4 too.
There is another problem related to the technique used to in extracting the children of selected directory. If the directory structure under the selected directory is very large, this makes the list of arguments too long thus making it impossible to start the sub process. Two things can be done to solve this problem. If the top most directory inside the archive is selected and there are no siblings for it, the command used should be the same as the one for extracting all files. If the above cannot be done, then the extraction must be done in steps by extracting a subset of the selected files files and then extracting the rest in further steps. This would reduce the number of arguments passed in each execution.
I've reported the above problem as a separate bug at http://bugs.kde.org/show_bug.cgi?id=150222
I see this line, Revived support for .tar, .tar.gz, and .tar.bz2 files in Ark. in this commit digest, http://commit-digest.org/issues/2007-12-30/ Does this mean this bug is fixed in KDE 4? Can someone please explain the current state? I apologize for not testing the latest build. I'm not finding enough time for it.
On Sat 05 Jan 2008 12:58:18 Chandra Sekar wrote: > ------- I see this line, > > Revived support for .tar, .tar.gz, and .tar.bz2 files in Ark. > > in this commit digest, > > http://commit-digest.org/issues/2007-12-30/ > > Does this mean this bug is fixed in KDE 4? Can someone please explain > the current state? > > I apologize for not testing the latest build. I'm not finding enough > time for it. No. Support for those file formats is broken in KDE4, and that plugin should not have been enabled by default. I asked the commiter to revert it, but he ignored me. In KDE 4.0.0, extracting tar files will randomly fail, and trying to add files to those archives will probably wipe the archive from the disk completely. I don't think anyone will use 4.0 though, so it shouldn't really be a problem...
Oh tats sounds scary. Hope it is fixed by 4.1
"I asked the commiter to revert it, but he ignored me. " Then do it yourself. It is better not to have the functionality accessible at all than something which could be destructive to the users' data.
I am still having the problem, if the first (or only) directory is chosen to extract. Been a long time with no fix!
Closing it as FIXED. Current versions of Ark use libarchive instead of relying on the command line.