Review Request 125974: Make KTar KCompressionDevice-friendly

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125974/#review88126
-----------------------------------------------------------


BTW why create a KTar on top of a KCompressionDevice? KTar is able to handle compression automatically all by itself... and that's exactly the case where it will use a tempfile for the uncompressed data, making seeking work. This patch is unnecessary if you use KTar the intended way: if the filename doesn't end with .gz or .bz2, specify the mimetype explicitly in the KTar constructor.

- David Faure


On Nov. 6, 2015, 2:52 a.m., Romário Rios wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125974/
> -----------------------------------------------------------
> 
> (Updated Nov. 6, 2015, 2:52 a.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: karchive
> 
> 
> Description
> -------
> 
> Up until now, since at least 5.12, decompressing some data coming directly from a QIODevice by using KCompressionDevice because this is a sequential device, and KTar and KArchive used to use QIODevice::seek and pos and some places, which made the decompression fail. This patch makes KTar sequential-friendly by replacing the calls to seek and pos with read and a simple counter, respectively.
> 
> 
> Diffs
> -----
> 
>   src/karchive.cpp 0ece37c 
>   src/ktar.cpp 824395e 
> 
> Diff: https://git.reviewboard.kde.org/r/125974/diff/
> 
> 
> Testing
> -------
> 
> Makes the tests from review #125941 pass
> 
> 
> Thanks,
> 
> Romário Rios
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151107/2340ed15/attachment.html>