(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: KDE 2.1.1 Severity: normal Installed from: SuSE RPMs Compiler: gcc 2.95.2 OS: Linux OS/Compiler notes: SuSE Linux 7.1 Professional Hi maybe my problem is in relation to some others reported. But anyhow I post it because none of the others does really fit ... I've downloaded the source archive for ghostscript 7.0 as a tar-archive being bzipped. Then I've tried to browse it under konqueror and the speed and so on was quite okay. Then I opened a new view dragged the folder contained in that archive to the home-directory. After some pause of 30 seconds at most he started copying by extracting. It looked like some hard work so I decided to do several things to give him some time. After ~10 minutes I came back and found copy process at 33%. Well bzip2-files are a bit slower than normal gzip. But this looks very inefficient. So I stopped this process and did the whole extraction by hand in about 30-60 seconds. Of course I could make it this way further on but this isn't the way you want users do it is it? My system is a UltraATA100-board (activated) with 256 Megs RAM and a 900 MHz Athlon processor so these can't be the reason too. The decompressed archive is 17Megs long. Thomas Urban (Submitted via bugs.kde.org)
On Sunday 06 May 2001 13:14 soletan@toxa.de wrote: > Package: konqueror > Version: KDE 2.1.1 > Severity: normal > Installed from: SuSE RPMs > Compiler: gcc 2.95.2 > OS: Linux > OS/Compiler notes: SuSE Linux 7.1 Professional > > Hi > > maybe my problem is in relation to some others reported. But anyhow I post it because none of the others does really fit ... > > I've downloaded the source archive for ghostscript 7.0 as a tar-archive being bzipped. > > Then I've tried to browse it under konqueror and the speed and so on was quite okay. Then I opened a new view dragged the folder contained in that archive to the home-directory. > > After some pause of 30 seconds at most he started copying by extracting. It looked like some hard work so I decided to do several things to give him some time. After ~10 minutes I came back and found copy process at 33%. > > Well bzip2-files are a bit slower than normal gzip. But this looks very inefficient. So I stopped this process and did the whole extraction by hand in about 30-60 seconds. > > Of course I could make it this way further on but this isn't the way you want users do it is it? Yes it's very slow because it opens 5 processes on the same archive to list and extract. Still not sure how to fix that it's KIO that launches processes this way. -- David FAURE david@mandrakesoft.com faure@kde.org http://perso.mandrakesoft.com/~david/ http://www.konqueror.org/ KDE Making The Future of Computing Available Today
Now, I'm somewhat astonished that this bug is that old and still not fixed. I'm no longer using Konqueror for anything related to tar archives because of it. Simply dragging a directory from a .tar.bz2 to some other directory takes an unreasonable amount of time. Every 2-5 seconds a *single file* is extracted. With code archives having some thousands of small files... Extracting the whole archive on the commandline however takes only 30 seconds. In the case of binutils-x.y.tar.bz2 kio is some 100 times slower than a simple tar -xvjf. I wonder if there's no possibility to fix this bug. After all, compressed archives are very common in the Linux world.
I guess I should apologize for the accusatory tone of my first comment. I'm sorry, I was in a bad mood and should have gotten some sleep first. Of course, kio is still one of the main reasons why KDE really rocks! :-)
Workaround: use Ark - Open the archive with ark - Select files/directories within the archive - Extract in the target location This is fast (on par with local 'tar [zj]xf'), and it takes only a few mouseclicks more. Since Ark is now integrated into KDE main, it could be used behind-the-scenes in Konqueror for drag-n-dropping parts of archives in reasonable time.
Subject: Re: extracting tar.bz2 archive after drag-n-drop is annoying slow On Friday 12 September 2003 00:17, you wrote: > Since Ark is now integrated into KDE main, it could be used behind-the-scenes > in Konqueror for drag-n-dropping parts of archives in reasonable time. This wouldn't make sense. Ark and Konqueror (well, the kioslave used by konqueror) actually use the same classes (kzip/ktar/kar). Konqueror uses all kioslaves the same way, and this gives stuff like "this file already exists" etc. (does ark do that?) The problem here is that several instances of the kioslave are launched at the same time, that's what makes this very slow. The missing feature is the ability to limit the number of kio_tar ioslaves working on the same tar file.
*** Bug has been marked as fixed ***.
I patched the ktar.cpp file to work on an uncompressed tar file instead of working on the compressed file through the compression filters.
*** Bug 75285 has been marked as a duplicate of this bug. ***
One more vote - I just tried to unpack kdevelop-3.0.1.tar.bz2 using konqueror. Ugghh.., I waited over 10 minutes, saw that I have 13% unpacked and clicked Cancel (on the very fast PC). The same file unpacks in less than 10 seconds using command line tar.
At what version is it claimed to be fixed? KDE 3.2 *is* terribly slow.
> At what version is it claimed to be fixed? CVS HEAD, post 3.3.