https://bugs.kde.org/show_bug.cgi?id=503364
--- Comment #2 from bryantc...@gmail.com --- So after poking around trying to wrap my head around the code every now and then I think I've somewhat understood what is going on. It isn't a bug, but how K7Zip is designed. It extracts all the entries data for each file entry on openArchive() and returns that on calling data() rather than doing what KZip, KTar, and the other archive types of KArchive that I am aware of do. Which is uses a KLimitedIODevice to read the data at that file entries position and size then decompress it with a KCompression device. This difference means that unlike the other archive types which open quickly because all they need is the position and size K7Zip has to decompress everything to memory. This is why when you try to open an unsupported compression type for K7Zip it will near instantly have the entry list with all it's information with the only thing being missing from the private entry is the data since it was unable to decompress it. Which is honestly how I expected it to behave just in general since none of the other archive types in KArchive extract the data when calling open(). The design leads to other issues like trying to open archives that are larger than system memory is not possible as far as I can tell. When I made a 7z archive larger than my memory and tried to open it via open() it just printed out "decode error" which is line 1844 and in the function K7Zip::K7ZipPrivate::readAndDecodePackedStreams. Unlike unsupported compression types though there was no entry list generated. Which makes sense I guess since that is one of the final things done in openArchive() in K7Zip. Although this could be some other issue because I have still yet to fully wrap my head around all the code in K7Zip. So while this is not a bug in that it's not functioning as it is designed I would call it's design a bug as far as the library is concerned. No other archive type in KArchive functions this way as far as I am aware. The general expectation is that it's an IO device for a file. So the memory footprint should be small at least compared to the size of the archive. It is simply just a way to interface with it. Unless there is some specific reason 7z can't be handled in that way, but seeing how other software out there seems to handle it I don't think that's the case. -- You are receiving this mail because: You are watching all bug changes.
