https://bugs.kde.org/show_bug.cgi?id=372023
--- Comment #8 from Theo <alpha0...@yahoo.de> ---
(In reply to Nikita Melnichenko from comment #7)
> if you feel like you can
> help figuring out the reason, you're more than welcome to do this. I can
> help you with the debugging setup, etc.
What would this setup roughly look like? Using my distributor's
debuginfo/debugsource packages and investigating with GDB, I can say the
following so far (note that I might not really know what I'm doing here, and
that I can provide details on my findings if necessary):
kio_iso uses KArchive's KCompressionDevice[1] to access the ISO file. The
device is created in KIso::prepareDevice and KCompressionDevice's constructor
creates a QIODevice and a QFileDevice. The corresponding *Private devices have
separate sets of member variables 'pos' and 'devicePos' that get out of sync
when the QFileDevice is closed at the end of KIso::openArchive. The QFileDevice
is reset to offset zero while QIODevice keeps the offset positions it has after
reading the ISO file system. When the ISO file is opened for reading the file
data, QFileDevice's offset positions are treated as if they haven't been reset
and subsequent seeks fall short of the requested offset.
Now I don't know whether QIODevice's offset should be reset when the
QFileDevice is closed after reading the file system or when it is opened for
reading the requested file data, but I tried the latter after reading the
following in the Qt documentation:
"When subclassing QIODevice, you must call QIODevice::seek() at the start of
your function to ensure integrity with QIODevice's built-in buffer."[2]
Replacing
if (size && !m_isoFile->device()->isOpen())
m_isoFile->device()->open(QIODevice::ReadOnly);
by
if (size && !m_isoFile->device()->isOpen()) {
m_isoFile->device()->open(QIODevice::ReadOnly);
m_isoFile->device()->seek(0);
}
in kio_isoProtocol::getFile (iso/iso.cpp) seems to work and I get the correct
file data on the first try.
This does not fix the issue of missing files in the directory listing, compare
for instance the contents of '/ISO9660' and '/El Torito BootJoliet level 3'
when browsing sgd_cdrom_1.30.iso as archive.
Regarding my question about reading through a lot of data when requesting file
data, it seems that the problem here is kio_iso's use of KCompressionDevice for
uncompressed ISO files. KCompressionDevice does not seem to support random
access and a seek is implemented as a read from the beginning, even for
uncompressed files. This seems like a really stupid idea since ISO files tend
to be big and should be read with a method that supports random access.
[1] https://api.kde.org/frameworks/karchive/html/classKCompressionDevice.html
[2] http://doc.qt.io/qt-5/qiodevice.html#seek
--
You are receiving this mail because:
You are watching all bug changes.
