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

[Luiz Romário Santana Rios]

2015-11-06 4:48 GMT-03:00 David Faure <faure at kde.org>:
> 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?)

Since I wait for the QNAM::finished() signal before doing anything
with the QNetworkReply, it probably does, but maybe not for, say, a
QTcpSocket. That case would need the waitFor*() calls, indeed.

>
> 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.

It already blocks, even in the KTar archive("file.tar.gz") case.

>
> 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.

Then we could use a temp file in the KZip implementation and this
approach for KTar?

>
> 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
>



-- 
Luiz Romário Santana Rios