Version: 0.12.10 (using KDE KDE 3.4.3)
Installed from: Debian testing/unstable Packages
Martin Trenz <email@example.com> reported the following problem on the Debian bug tracking system (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345766).
A log of the k3b messages is at
and a screenshot of the problem is at
When burning CD/CD-RW/DVD+RW (DVD+R not tested) with "verify on" the
burn itself works fine but verifying fails with "Could not find file
<first file in set>. Size and number of files are irrelevant. Names of
files are also irrelevant (no special chars, happens with "1.mpg"). Testet
with two different burners. The burned media is OK, the files can be
sucessfully verified with "diff" and "md5sum" after mounting the media
The Message pops up at exactly 50% of the first file and to fast to have
k3b had accessed the CD-drive. My guess is that the 50% means that k3b did the
md5-calculation of the file as it is on the HD, then tries to find the
file on the CD and fails. Remounting between burn and verify takes
place, the message "Rereading TOC" can be seen. There is no mentioning of
the error-message in the k3b debug-log. There are no relevant messages in
the syslog except "k3b: resmgr: communication failure: Datei oder
Verzeichnis nicht gefunden" (file not found), but this has been so for
a long time and never caused problems. When starting k3b in a shell
there are no relevant messages at the time of the problem.
what are your locale settings?
Here's Martin's response:
mtrenz@speedy:~$ env|grep LC
mtrenz@speedy:~$ env|grep LANG
It seems my LC* variables are not set, but i don't know why.
Just another datapoint, I'm using K3b as packaged in Debian Sid, and while CD verify worked fine, DVD-r is displaying this behavior. I just realized that the CDs that verified correctly were .ISO burns, not individual files, I would be interested if this problem is occurring for anyone else with DVD .ISO burning. I don't have a DVD .ISO file to test with.
iso files always work as they are compared "as is" while for data projects (CD
and DVD) k3b tries to compare the data for every file to know which files are
Further data points: (I'm running k3b 0.10.12-1 from Debian but compiled against Sarge's KDE 3.4.3):
- This is not specific to changes in KDE 3.5
- It breaks for me when composing individual file for a DVD, I didn't burn an ISO image
I've tried 0.12.10 and 0.12.9, both show the same bug.
I tried 0.12.8 and it works, so it broke between 0.12.8 and 0.12.9.
I have same problem on k3b-0.12.10(compiled from tarball).
I found that if I enabled "Allow lowercase characters in ISO9660 filenames" option, verifying works fine.
Some debug prints I inserted indicates that d->currentItem->iso9660Path() in void K3bDataVerifyingJob::slotMd5JobFinished( bool success ) uses upper case filename, but void K3bIso9660Directory::addEntry( K3bIso9660Entry* entry ) adds lower case filename (it is same as original filename) to m_iso9660Entries,
so verifying will fail.
thanks a lot for this information. I was not able to reproduce the bug yet.
Now i know where to search and and can hopefully fix it. :)
stupid me. I already fixed this bug weeks ago. I was just confused since I did not have much time for k3b...
*** Bug has been marked as fixed ***.
Could you post which version the problem was fixed in, so I could watch ofr it to appear in Debian Sid?
As an aside, are any incompatibilities introduced by checking the "allow lower case letters" as suggested above?
0.12.11 will be released soon.
allow lower case is enabled by mkisofs when using "untranslated filenames" k3b
< 0.12.11 did not take this into account.
Sorry but with k3b 0.12.12 I still have the "Could not find..." problem that's been present since k3b 0.12.9 when verifying a DVD-R. Files on the disk are my weekly backups, with names (this week):
1797908809 2006-02-19 21:19 david-2006-02-19.tar.bz2
1387261 2006-02-19 21:19 etc-2006-02-19.tar.bz2
874850689 2006-02-19 21:54 win-2006-02-19.tar.bz2
K3b always fails to find the david-yyyy-mm-dd.tar.bz2 file. The only difference with k3b 0.12.12 is that it gets to 33% before reporting that it could not find the file. Previously it would stop right at the start of the verify step.
Calculating md5sums has always indicated that the burn was fine.
k3b 0.12.12 (burning using K3b default settings + verify + no multisession)
kde 3.5.1 (but using the Gnome 2.12.2 desktop)
Since I cannot reproduce the problem here, is there any way I could get a ssh connection with x forwarding to test it on another system?
problem went away for me with enabling the following advanced options:
allow 103 ch. joliet file names
allow 31 ch. iso9660 file names
allow leading periods in iso9660 file names
allow multiple dots in iso9660 file names
allow lowercase characters in iso9660 file names
I believe the last one did the trick; char. length limits i had already on, and the dot options i added for caution.
Debian Sarge (stable) with some Etch (testing)
YMMV, as always. Good Luck.
I can confirm I still have exactly this same bug on Ubuntu 6.10 (Edgy) (K3b: 0.12.17 , KDE: 3.5.5)
The "Allow lowercase characters in ISO9660 file names" option is what matters. I checked that a CD with
* hello.txt with the option off fails verification.
* hello.txt with the option on succeeds.
* HELLO.TXT with the option on or off succeeds.
The bug is in not having that option on by default and in depending on that option to work (or, having that as an "option" at all, if it is a necessary one).
I also reported this in Ubuntu: https://launchpad.net/distros/ubuntu/+source/k3b/+bug/59089
1.0 fixed that.