Ubuntu

k3b can't find bin file in the same directory

Reported by Marco Rodrigues on 2006-12-15
2
Affects Status Importance Assigned to Milestone
KDE Multimedia
Confirmed
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!

Marco Rodrigues (gothicx) wrote :

See the screenshot!

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
Marco Rodrigues (gothicx) wrote :

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

It's there and in lowercase =)

jcfp (jcfp) wrote :

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

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.

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.

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

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
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
jcfp (jcfp) wrote :

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

Kenny Duffus (kduffus) on 2006-12-16
Changed in k3b:
importance: Undecided → Wishlist
Changed in kdemultimedia:
status: Unknown → Confirmed
Marco Rodrigues (gothicx) wrote :

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

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