Failure while executing KTar::open while using KCompressionDevice as the device

David Faure faure at kde.org
Fri Nov 6 07:48:57 UTC 2015


On Monday 02 November 2015 14:53:40 Luiz Romário Santana Rios wrote:
> 
> I'm trying to decompress a XZ archive downloaded using
> QNetworkAccessManager, so, according to the documents, I have to pass
> the QNetworkReply pointer to a KCompressionDevice 

I don't think this can work at all.
(and yes I've seen your review request, but while it fixes the file:/// case, are you sure
it fixes the network case as well?)

Here's the issue:
while QIODevice is indeed one single API, there are two ways to use it:
push and pull.  Or in other words, async and sync.

The push / async use case is the one used with sockets (including QNetworkReply).
You wait for data to be available and only then read it. Waiting can be done blocking
or with the event loop (signal/slot connection).

The pull / sync use case is code that assumes there's always data available,
as is the case with QFile, QBuffer etc. This is what KCompressionDevice, KTar, KZip
etc. all assume.

So the reason it breaks (apart from the issue of seeking) is that when KTar
(or KCompressionDevice) wants to read more data, it might not be available,
and the read fails. You could add waitFor* calls, but that would make the whole
thing blocking - very bad for the main thread of a GUI program.

So instead I do recommend using KIO (or QNAM) to make an async download
(keeping the GUI reactive, allowing for a progress bar if desired...), and only
once the stuff is in a tempfile, you can create a KArchive on top.

KTar is somewhat linear so your patch + waitFor* might make it work but
KZip requires a lot more going back and forth in the file, so this will never work
without a temp file.

In the special case of tar+compression in readonly mode, KTar already creates
a temp file, for the uncompressed tar, for faster seeking. This might also be
why you make it work in this very case, but that doesn't help for the other cases
(not tar, or not compressed)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list