Loading file data from an ISO image via the ISO KIO Slave reads the ISO image file from the beginning every time. For big image files this is a huge waste of time and resource. The cause seems to be the usage of KArchives's KCompressionDevice[1], for which the authors have not bothered to implement a random access mechanism. Instead, seeks are realized as reads from the beginning. Would QFile[2] be a better alternative for uncompressed image files? [1] https://api.kde.org/frameworks/karchive/html/classKCompressionDevice.html [2] http://doc.qt.io/qt-5/qfile.html
(In reply to Theo from comment #0) > Would QFile[2] be a better alternative for uncompressed image > files? This seems to work for me. With the following I don't have to wait an unacceptable amount of time every time I open a file from a big ISO image: I added the lines else if ("model/x.stl-binary") { setDevice(new QFile(filename)); } after if ("inode/blockdevice" == mimetype) setDevice(new QFileHack(filename)); in void KIso::prepareDevice(const QString & filename, const QString & mimetype, bool forced) in kiso.cpp. The mime type of ISO files is actually "application/x-cd-image", but there is an unfixed bug[1] that causes them to be wrongly detected as "model/x.stl-binary", so I used this for my test. [1] https://bugs.freedesktop.org/show_bug.cgi?id=99421#c15
(In reply to Theo from comment #1) > else if ("model/x.stl-binary") { Obviously, this must read else if ("model/x.stl-binary" == mimtype) { but this turns out to not work that well after all because MIME type detection seems to be unreliable, even if we ignore the false detection as "model/x.stl-binary", which, as opposed to my earlier claim, has been fixed recently: https://bugs.freedesktop.org/show_bug.cgi?id=106330#c21 Testing some more ISO images, I came across a image file that is detected as "text/plain", while others are correctly detected as "application/x-cd-image" by kmimetypefinder5, but are passed as "application/octet-stream" to KIso::prepareDevice in iso/kiso.cpp. So to make it work with all of my sample ISOs, I used the following atrocity: else if ("model/x.stl-binary" == mimetype || "application/octet-stream" == mimetype || "text/plain" == mimetype) { setDevice(new QFile(filename)); } I think KIso::KIso and KIso::prepareDevice (kiso.cpp) need some attention by someone who knows how to handle MIME type detection. Right now it seems to be quite a mess: Why is KIso::KIso considering compressed tar filed? Why does it care about KOffice docs? Why are gzip and bzip2 treated explicitly, as opposed to xz, which also works? Why are ISOs detected as "application/octet-stream", although kmimetypefinder5 sees them as "application/x-cd-image"?
You ask good questions. I guess we may get some answers if we check the code change history (git blame or similar tool). Currently I can't confirm the bug. I browse a >1Gb iso file, read files in it and IO monitor doesn't show any huge activity. Can you elaborate on this? Is it possible to confirm without debugging the read calls?
(In reply to Nikita Melnichenko from comment #3) > Currently I can't confirm the bug. I browse a >1Gb iso file, read files in > it and IO monitor doesn't show any huge activity. Can you elaborate on this? > Is it possible to confirm without debugging the read calls? The problem should be obvious from the time it takes to load a file from the ISO iamge. I can also see it by monitoring Disk Troughput/<device>/Rate/Read Data in KDE System Monitor. I should mention that I need to do $ echo 3 > /proc/sys/vm/drop_caches after each try if the image file is only 1GB or so in size. Otherwise, the data will come from the cache. I noticed the problem first with a 3.4 GB ISO, which is too big to be cached: http://distfiles.gentoo.org/releases/x86/12.0/livedvd-x86-amd64-32ul-2012.iso (this one is detected as MIME type "text/plain", see https://bugs.freedesktop.org/show_bug.cgi?id=80877).
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!