k3b can't find bin file in the same directory

[Marco Rodrigues]

Binary package hint: k3b

System
-----------------------
K3b Version: 0.12.17

KDE Version: 3.5.5
QT Version: 3.3.6
Kernel: 2.6.17-10-generic
Devices
-----------------------
HL-DT-ST DVDRAM GSA-4167B DL13 (/dev/hdd, ) at /media/cdrom0 [CD-R; CD-RW; CD-ROM; DVD-ROM; DVD-RAM; DVD-R; DVD-RW; DVD-R DL; DVD+R; DVD+RW; DVD+R DL] [DVD-ROM; DVD-R Sequential; DVD-R Dual Layer Sequential; DVD-RAM; DVD-RW Restricted Overwrite; DVD-RW Sequential; DVD+RW; DVD+R; DVD+R Double Layer; CD-ROM; CD-R; CD-RW] [SAO; TAO; RAW; SAO/R96P; SAO/R96R; RAW/R16; RAW/R96P; RAW/R96R; Restricted Overwrite]

Used versions
-----------------------
cdrdao: 1.2.1

cdrdao
-----------------------
Cdrdao version 1.2.1 - (C) Andreas Mueller <email address hidden>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty
Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.
ERROR: Could not find input file "RLD-D3A.BIN".

cdrdao command:
-----------------------
/usr/bin/X11/cdrdao write --device /dev/hdd --speed 32 -n -v 2 --force --remote 16 /home/kmos/downloads/DOOM.3-RELOADED/CD1/rld-d3a.cue

I'm using Ubuntu Edgy :-) I've rld-d3a.bin in the same directory of .cue file, so why it can't find it!

[RIchard (rlees)]

Version: 0.11.10 (using KDE 3.2.2, Gentoo)
Compiler: gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)
OS: Linux (i686) release 2.4.26-gentoo-r6

My 1st time trying to burn a .cue/.bin file and it didn't work right off because the Windoze file had CAPS in the .cue file for the name of the .bin file. Of course the Linux file name was not in caps so I got the message "Seems not to be a usable image." because it couldn't find the context-sensitive .bin file listed in .cue.

Changing the .cue file to lower-case solved the problem.

Suggestions:
 - if the .bin file can't be found, check for non-case-sensitive and continue or offer to continue if it's found.
 - OR, expand this error message a bit to explain what the problem is (ie. matching .bin file listed in .cue can not be found. Check case-sensitive .cue file." would be better.

[Christoph Burger-Scheidlin (andersin)]

*** Bug 107359 has been marked as a duplicate of this bug. ***

[Christoph Burger-Scheidlin (andersin)]

*** Bug 136600 has been marked as a duplicate of this bug. ***

[Christoph Burger-Scheidlin (andersin)]

renamed after I was hard pressed to find it again. Changing to NEW to indicate that it is something that people ran into more frequently.

[Marco Rodrigues (gothicx)]

See the screenshot!

[jcfp (jcfp)]

According to that screenshot k3b is looking for (all caps) "RLD-D3A.BIN". Are you sure that file exists? Note that (lowercase) "rld-d3a.bin" would be a different filename on linux/unix systems.

[Marco Rodrigues (gothicx)]

kmos@bash:/downloads/DOOM.3-RELOADED/CD1$ ls
rld-d3a.bin rld-d3a.cue

It's there and in lowercase =)

[jcfp (jcfp)]

Could you check the cue file, to see whether it specifies the file name for the bin file in upper case?

[Marco Rodrigues (gothicx)]

RLD-D3A.CUE content:

FILE "RLD-D3A.BIN" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00

That's it! I don't know why cdrecord doesn't check this.. if the file is there.

[jcfp (jcfp)]

Yes that is what is causing the burning to fail, and that by itself is an error of whoever/whatever created that cue file.

But... k3b does pretend to find the bin file without any problem and calculates the md5 sum for it in the selection dialog, even when the filename specified in the cue file is wrong because of upper vs lower case.

Next, upon burning, the cdrecord tools try to use the bin filename exactly as found in the cue file (as they should!) and fail (no surprise there).

So that would be a bug. Either it should not pretend all is well when selecting the cue file (and instead warn the user); or when accepting a "wrongly named" bin file, it should make sure burning works correctly (for example by feeding a corrected copy of the cue file to cdrecord).

Anyway, current behaviour is counter-intuitive and wrong.

[Marco Rodrigues (gothicx)]

I've changed cue file manually and it burned fine. Now I think someone need to fix this, the program itself can't trust on a cue file, it should be a insensitive case check-verification-file..

[Kenny Duffus (kduffus)]

Linux and other UNIX like operating systems (mainly) use a case sensitive file system, there for if the .cue file has the wrong name for the bin file (a lowercase filename is a different file from a similarly named uppercase file) k3b is correct to say it can't find the file. The problem is more to do with what ever created the .cue file or the way the files were transferred.

[jcfp (jcfp)]

@Kenny Duffus: you would be right, in case k3b would reject the cue file when loading it (see my comment of 2006-12-15 20:42:50). But it doesn't give an error, complain, or even notify the user at that time. Instead, working around this problem was purposely implemented as a feature in k3b [*].

From the user perspective all is well, until the user initiates the burning process which will always fail because k3b sends the cue file unmodified to cdrecord/cdrdao. Either refuse the cue file at the start (or at least warn/inform the user), or make sure the workaround actually works completely (so that the user can successfully burn the image).

[*] See: http://bugs.kde.org/show_bug.cgi?id=115755
as well as (comment #2 on) http://bugs.kde.org/show_bug.cgi?id=136600

[jcfp (jcfp)]

Upstream can be found here: http://bugs.kde.org/show_bug.cgi?id=87231

[yamal (kubuntu-uhn-noc)]

In 0.12.17 (0.12.17-1ubuntu3) k3b's selection dialog guesses the correct bin file when loading a cue file that has the bin's filename with the wrong case. No error or notification is shown to the user and md5 gets calculated normally, suggesting all is okay to start burning.

However, burning still fails because k3b passes the original cue file to cdrecord/cdrdao, which causes those to not find the bin file.

So part of the suggestions made by the original reporter have been implemented (http://bugs.kde.org/show_bug.cgi?id=115755), but in such a way that actually burning the image will unfortunately still fail.

This was reported in Ubuntu as http://launchpad.net/bugs/75887

[Trueg (trueg)]

*** Bug 140200 has been marked as a duplicate of this bug. ***

[Trueg (trueg)]

*** Bug 142635 has been marked as a duplicate of this bug. ***

[Marco Rodrigues (gothicx)]

Anyone knows if this bug/wish is fixed/released on v1.0 ?

[jcfp (jcfp)]

Doesn't look like it, see http://bugs.kde.org/show_bug.cgi?id=142635 which reports this issue still present in 1.0rc6