k3b can't find bin file in the same directory

Bug #75887 reported by Marco Rodrigues
2
Affects Status Importance Assigned to Milestone
KDE Multimedia
Unknown
Wishlist
k3b (Ubuntu)
Wishlist
Unassigned

Bug Description

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!

Revision history for this message
In , RIchard (rlees) wrote :

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.

Revision history for this message
In , Christoph Burger-Scheidlin (andersin) wrote :

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

Revision history for this message
In , Christoph Burger-Scheidlin (andersin) wrote :

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

Revision history for this message
In , Christoph Burger-Scheidlin (andersin) wrote :

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.

Revision history for this message
Marco Rodrigues (gothicx) wrote :

See the screenshot!

Revision history for this message
jcfp (jcfp) wrote :

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.

Changed in k3b:
status: Unconfirmed → Needs Info
Revision history for this message
Marco Rodrigues (gothicx) wrote :

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

It's there and in lowercase =)

Revision history for this message
jcfp (jcfp) wrote :

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

Revision history for this message
Marco Rodrigues (gothicx) wrote :

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.

Revision history for this message
jcfp (jcfp) wrote :

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.

Revision history for this message
Marco Rodrigues (gothicx) wrote :

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..

Revision history for this message
Kenny Duffus (kduffus) wrote :

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.

Changed in k3b:
status: Needs Info → Rejected
Revision history for this message
jcfp (jcfp) wrote :

@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

Changed in k3b:
status: Rejected → Confirmed
Revision history for this message
jcfp (jcfp) wrote :

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

Revision history for this message
In , yamal (kubuntu-uhn-noc) wrote :

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

Kenny Duffus (kduffus)
Changed in k3b:
importance: Undecided → Wishlist
Changed in kdemultimedia:
status: Unknown → Confirmed
Revision history for this message
In , Trueg (trueg) wrote :

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

Revision history for this message
In , Trueg (trueg) wrote :

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

Revision history for this message
Marco Rodrigues (gothicx) wrote :

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

Revision history for this message
jcfp (jcfp) wrote :

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

Changed in k3b:
status: Confirmed → Triaged
Changed in kdemultimedia:
importance: Unknown → Wishlist
Changed in kdemultimedia:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.