----------------------------------------------------------- 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
