https://bugs.kde.org/show_bug.cgi?id=372023
--- Comment #6 from Theo <alpha0...@yahoo.de> --- (In reply to Nikita Melnichenko from comment #5) > (In reply to Theo from comment #4) > > It happens with every ISO image I try. I did a test with a small sample size > > of ISO images and the data offset seems to be off by the same sector count > > on the first try for a given ISO. I got 52, 64, and 80 2K sectors ahead for > > three different CDs/DVDs. > > How did you determine this? By brute force. I opened a file on the ISO with Okteta using iso:/, copied the first 16 bytes of binary garbage in hex format, then fed this into a binary grep on the whole ISO image to get the offset. The same for the correct data after reloading the file. I did this for more than one file for every tested ISO image. I use https://github.com/tmbinc/bgrep for the binary grep, but it should also be possible to use standard grep (or some other method), albeit not as fast: https://stackoverflow.com/questions/4180081/binary-grep-on-linux/17168777#17168777 Example: $ okteta iso:/home/user/sgd_cdrom_1.30.iso/ISO9660/grubdetect.lua $ bgrep -A 20 C78508FFFFFF00000000C7850CFFFFFF sgd_cdrom_1.30.iso | sed 's/\\x//g' sgd_cdrom_1.30.iso: 00042800 c78508ffffff00000000c7850cffffff00000080 sgd_cdrom_1.30.iso: 00042872 c78508ffffff00000000c7850cffffff00000000 In this case I have to use "-A" to check that the first match is the correct one. After reloading the file in Okteta: $ bgrep 23216C75610A0A66756E6374696F6E20 sgd_cdrom_1.30.iso sgd_cdrom_1.30.iso: 0005c800 $ echo 'ibase=16;(0005C800-00042800)/800' | bc -l 52.00000000000000000000 > > For instance, for > > > > https://sourceforge.net/projects/supergrub2/files/1.30/ > > > > kio_iso seems to deliver data that is 52 sectors ahead on the first try. > > This image is not identified as ISO in my krusader (v2.7). Could this be related to this annoyance: https://bugs.freedesktop.org/show_bug.cgi?id=99421#c20? I get this nonsense: $ kmimetypefinder5 sgd_cdrom_1.30.iso model/x.stl-binary > Dolphin > recognizes it fine and reads from the first try. For example, I can browse to > > iso:/.../sgd_cdrom_1.30.iso/El Torito BootJoliet level 3/boot/grub/ > > without a problem. If the link is directly copied to Krusader, it also opens > the link fine. Doesn't make a difference whether I use Krusader or any other KDE program. It seems to depend only on the iso:/ protocol. Did you also try opening a file on the ISO to check if the data is correct? There might also be a problem with some missing files in the directory listing (comment #0). > > By the way, is it normal that a lot of data is read when I access a small > > file on a big ISO image? > > I'm not sure as I'm not familiar with the format. It's unexpected because one should get the position of the file from the file system on the ISO and then go directly to the file without reading a lot of data from the image. But maybe I have a completely wrong idea about how ISO 9606 works... -- You are receiving this mail because: You are watching all bug changes.
