Version: (using KDE KDE 3.5.7) Installed from: SuSE RPMs Compiler: gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=i586-suse-linux OS: Linux I've got several JPEG2000 files in a directory. Konqueror couldn't show any previews and couldn't launch an embedded viewer. The reason: no correct magic data for KMimeMagic. In the attachment you'll find a patch with the needed magic data. Also I noticed that the magic file was parsed several times to determine the type of the same file (or the same buffer) even though the type was determined after the first time and no additional parsing was necessary. Therefore I added some code (take a look at the attachment) to prevent unnecessary parsing of magic data for the same file/buffer. And another thing: here you can find several JPEG2000 files http://www.microimages.com/gallery/jp2/ http://www.openjpeg.org/index.php?menu=samples e.g. http://www.microimages.com/gallery/jp2/1.jp2 http://www.openjpeg.org/samples/Cevennes2.jp2 Konqueror doesn't view them correctly because they are treated not as JPEG200 files but e.g. as text/plain (http://www.microimages.com/gallery/jp2/1.jp2) or as application/octet-stream (http://www.openjpeg.org/samples/Cevennes2.jp2). It is obvious that KIO relies on what the respective server is telling it. Expected behavior: Konqueror should be able to view those files. Possible solution: when a file is viewed it is downloaded anyway therefore KIO can stop listening to what the server is telling it and just parse the downloaded file which always produces the correct result.
Created attachment 21329 [details] kio.diff
Please also send your patch to kde-core-devel@kde.org - it'll get more attention from developers there. Thanks!
Hi, thanks for the patch. The code changes are unrelated to jpeg2000 and seem to leak QByteArrays and QFileInfos ("new" can be called multiple times before the "delete" is called, so the memory is leaked). The magic file changes are a bit strange as well: 3 belong 0x00000c6a5020 image/jp2 4 string jP image/jp2 This seems redundant. How can there be a 6-bytes number starting at offset 3 and a two-char string starting at offset 4? Or is this because some files have one and some files have the other? Is there a specification of the jpeg2000 header somewhere? Anyway the main issue is that this is dead code. KMimeMagic is gone in kde4, replaced with code that handles XDG (freedesktop.org) shared-mime-info. See http://standards.freedesktop.org/shared-mime-info-spec/latest/ So for this fix to survive in the long term: 1) the changes to the magic file should be adapted to freedesktop.org.xml.in (which you can find with cvs co -d :pserver:anoncvs@anoncvs.freedesktop.org:/cvs/mime shared-mime-info) Currently it doesn't have any magic, only <glob pattern="*.jp2"/> 2) the change to freedesktop.org.xml.in should be posted into a new bug report at https://bugs.freedesktop.org/enter_bug.cgi?product=shared-mime-info Thanks!
Actually, the code changes are related not only to jpeg2000 files but also to any other file that's accessed through KIO (I had a problem with jpeg2000 so I posted the changes here but it could've been a separate bug report). What's strange is that a file or a buffer is accessed several times 'cause that shouldn't happen in the first place. And thanks for the info about memory leaks, it's fixed now. I could provide the improved patch but since it's dead code anyway it doesn't matter. These are alternatives (I forgot to comment out the second line): 3 belong 0x00000c6a5020 image/jp2 #4 string jP image/jp2 > Is there a specification of the jpeg2000 header somewhere? For the magic data that I provided I analyzed several jpeg2000 files both on the internet and on a local hard drive. But there is a specification: http://www.rfc-editor.org/rfc/rfc3745.txt. And there's also a problem: the magic number (12 byte string: X'0000 000C 6A50 2020 0D0A 870A') can't always be matched. I found several jpeg2000 files with '0020 000C' therefore I defined the 3-byte offset. New bug report was created: https://bugs.freedesktop.org/show_bug.cgi?id=11942 It looks like I'll have to install KDE 4 to continue my bug hunting and to avoid dead code patches ;-)
In freedesktop's hands now, closing the kde report.