Version: 1.69.0 (using KDE 4.2.4) OS: Linux Installed from: Slackware Packages When I create a DVD image containing a file which is bigger than 4 GB, then mount the image with "mount -o loop", most of the files in the image are corrupted. I have used the "Very Large Files (UDF)" filesystem option. But if I use mkisofs directly, the files in the image are correct (checked with md5sum). The command I used is based on the command that k3b itself runs: /usr/bin/mkisofs -volid 'foo' -rational-rock -joliet -joliet-long -no-cache-inodes -udf -full-iso9660-filenames -iso-level 3 -o bar.iso /path/to/files/* The version of mkisofs is: mkisofs 2.01.01a57 (x86_64-unknown-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2008 Jörg Schilling The version of k3b is 1.69.0alpha4, however I have produced it with k3b 1.0.5 as well. Perhaps the problem is in mkisofs or the way it is used. Please let me know if more information is required.
SVN commit 1079204 by mmalek: * Initialize AbstractCdrtoolsProgram::m_usingCdrkit member, otherwise the cdrtools/cdrkit programs aren't detected at random times. * Cleanup in ExternalBinManager BUG: 221638 M +20 -19 k3bdefaultexternalprograms.cpp M +2 -2 k3bdefaultexternalprograms.h M +10 -8 k3bexternalbinmanager.cpp M +4 -4 k3bexternalbinmanager.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1079204
Sorry, above message was meant for bug 221945.
In an attempt to clean up old bugs that are not valid for K3b 2.0 (=KDE SC 4.x port) anymore, this is now being marked as UNMAINTAINED. If this bug is still valid for 2.0, please reopen it.
Bug still valid, now on Slackware 13.1 with K3B 2.0.0 and mkisofs 2.01.01a78
This bug is still valid for me with cdrtools 3.0 / k3b 2.01 on Slackware64 current (kde4.5.3) When mixing file sizes, only files larger than 4GB are valid, all smaller files are corrupted. What is very strange is that it is always reproducible and always files > 4GB valid. I will try creating the image directly with mkisofs without k3b (with similar command line like Peter did) and change k3b options to see what corrupts data Saving the iso file (without burning) exposes the same problem (-o loop) so the media/burn part doesn't seem affected