Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 110432 - cdrecord truncating files
cdrecord truncating files
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: cdrtools (Show other bugs)
1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2003-11-19 10:59 EST by Need Real Name
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-16 09:54:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Need Real Name 2003-11-19 10:59:03 EST 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
I was trying to use K3B to burn some bin/cues when it kept telling me
that the cue file wasn't valid. I checked the file and it was empty
and was 0 bytes.  I rebuilt it and tried again to get the same error.
Looked at the file and it was empty again. Not only that but the BIN
file had been truncated to 0 bytes as well.  I tried 2 other bin/cues
just to test, it truncated all of them.  The error was coming from
cdrecord so I figured this was the problem, did it on command line and
it did the same, so I found the RedHat 9 RPM of it and installed that
overtop the fedora one and tried agian, and it burned properly.  So
there is some serious error in cdrecord which is truncating the files.
 The only other thing I can think of to say that might help is I
believe all the ones I test with were mode 2.  I didn't have any ISOs
handy to test to see if it was doing it was everything.

Version-Release number of selected component (if applicable):
cdrecord-2.01-0.a19.2

How reproducible:
Always

Steps to Reproduce:
1. Make sure you are using the cdrecord that is stock with fedora core 1
2. Try to burn a mode 2 bin/cue (maybe other formats) 
3. Watch as it fails ;)
    

Actual Results:  Truncates the files down to 0 bytes.

Expected Results:  Leave the files untouched and burn them.

Additional info:
Comment 1 Harald Hoyer 2004-01-29 05:01:06 EST 
cue and bin files are generated from cdrdao... not cdrecord!
Comment 2 Need Real Name 2004-01-29 08:34:11 EST 
I was not MAKING bin/cues, I was trying to burn them.  And cdrecord
was the problem because changing the version fixed it, and I
reproduced this bug by using the command line to try to burn the CD,
which I believe I stated in the original report.  Obviously when using
the command line, I know I was using cdrecord.

cdrecord would just remove all the data in the files and leave them as
0 bytes, which is a MAJOR problem since it shouldn't change the files
AT ALL. It should only read them. So anyway, like I said, I was not
trying to generate bin/cues.
Comment 3 Harald Hoyer 2004-01-29 09:59:41 EST 
huh? you used cdrecord to burn bin/cue?? didn't know this works... I
use cdrdao for this...
Comment 4 Need Real Name 2004-01-29 10:30:58 EST 
Hmm.. well I am not in linux atm nor do I have those bin/cues anymore,
but k3b shows the commands it is running somewhere, and I saw that and
just ran that command verbatum and got the same results and errors as
k3b gave.  I believe once I got it working I tried it on the command
line again and it worked there as well. So I don't remember what I put
in there exactly right now, I do know you can check if you have a copy
of k3b.  If not I can check at a later date and post back here with
the command I used.
Comment 5 Harald Hoyer 2005-09-16 09:54:54 EDT 
CANTFIX without more information, closed due to inactivity.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.