mkisofs | cdrecord for files > 2GB

An update: after jumping through all of the hoops to compile Cdrtools
(Joerg's programs require Joerg's Make clone), the new cdrecord fails
to burn ISOs to DVDs (the old version bundled with InfraRecorder works
though) - a warning about conflicting device sizes is followed by an
error when trying to write.

js@cs.tu-berlin.de (Joerg Schilling) writes:

>In article <SeYrj.18908$w57.3647@edtnps90>,
>Unruh <unruh-spam@physics.ubc.ca> wrote:
>>js@cs.tu-berlin.de (Joerg Schilling) writes:
>>
>>>In article <ErKrj.18747$w57.2465@edtnps90>,
>>>Unruh <unruh-spam@physics.ubc.ca> wrote:
>>
>>>> As I recall, the main reason the fork was created was not licensing but DVD support
>>>>which cdrecord did not have at the time (except in a proprietary version)
>>
>>>First, the DVD support code was free for some time _before_ the fork
>>>has been created. See:
>>
>>No, it was free for personal use only. It could not, for example, be
>>included in any distro.

>The DVD support code is included in the OpenSource code tree since
>May 15th 2006, the Debian fork first appeared on September 3rd 2006.

>Are you shure that you are not mistaken?

There was a fork of cdrecord back in 2004 or so in which I think it was
warley from Mandriva had inserted dvd recording into cdrecord. As I recall,
the debian fork then went off that that effort. I use mandriva so do not
recall the Debian situation at all well, and you may be right on the Debian
story.

So, yes, I could well be mistaken about Debian.

In article <f1763b7c-efb4-4857-a18f-237826d970a4@q77g2000hsh.googlegroups.com>,
jhc0033@gmail.com <jhc0033@gmail.com> wrote:
>An update: after jumping through all of the hoops to compile Cdrtools
>(Joerg's programs require Joerg's Make clone), the new cdrecord fails

If you are on *BSD, then you are correct, the make clone that is shipped
with *BSD is unfortunately not useful for portable sources.

We first thought that only modern features (like pattern matching macro
expansions) are missing in the *BSD make clone and so I added this
feature together with a FreeBSD person. Then we found that the *BSD make clone
is not sufficiently compatible to the standard make(1) program because it treats
path names diffrerent from the standard. It is not possible to fix this problem
without breaking the ability to compile the *BSD kernel sources.

The "schily makefile system" that gives portability to my software works with
three make programs, all are OpenSource:

1) The current descendant from the original UNIX make program:
"SunPro make". It works on Solaris, Linux and probably on *BSD

1a) The same program shipped as "distributed make (dmake)" is
available for binary download together with the Sun Studio compiler
for Solaris and Linux

2) A make clone called "GNU make" from 1987 that is available as
/bin/make on Linux.

It gives medium portability (it compiles on many plaforms but
does not work on all of them).

3) My make clone called "smake" from 1984. It is the most portable
make program and for this reason the preferred make program.


>to burn ISOs to DVDs (the old version bundled with InfraRecorder works
>though) - a warning about conflicting device sizes is followed by an
>error when trying to write.

As you claim that you compiled it but do not provide any evidence for
problems, this is hard to believe....

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

"jhc0033@gmail.com" <jhc0033@gmail.com> writes:

>An update: after jumping through all of the hoops to compile Cdrtools
>(Joerg's programs require Joerg's Make clone), the new cdrecord fails
>to burn ISOs to DVDs (the old version bundled with InfraRecorder works
>though) - a warning about conflicting device sizes is followed by an
>error when trying to write.

It would of course be helpful is you cut and pasted the exact error code
and warning. Are you sure that you eliminated all of the old code from your
system. Ie, it is possible that you are running a bastardized system in
which some programs are the old ones and some the new.
Note that I have never had any problems compiling cdrtools, and as far as I
know have never installed "Joerg's Make clone" on my system.

On Feb 11, 1:32 pm, j...@cs.tu-berlin.de (Joerg Schilling) wrote:

> If you are on *BSD,

Cygwin (I mentioned this in my original message)

> As you claim that you compiled it but do not provide any evidence for
> problems, this is hard to believe....

(long paste of commands and output - with apologies for what's
probably now off-topic in both groups)

HTH


$ mkisofs.exe -version
mkisofs 2.01.01a37 (i686-pc-cygwin) Copyright (C) 1993-1997 Eric
Youngdale (C) 1997-2007 Jörg Schilling

$ mkisofs -gui -iso-level 4 -J -joliet-long -r -o foo.iso /usr/local/
bin/cdrecord.exe
Warning: Creating ISO-9660:1999 (version 2) filesystem.
Warning: ISO-9660 filenames longer than 31 may cause buffer overflows
in the OS.
Total translation table size: 0
Total rockridge attributes bytes: 277
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 20000
404 extents written (0 MB)

$ /bin/ls -l foo.iso
-rw-r--r-- 1 jhc None 827392 Feb 11 23:13 foo.iso

$ cdrecord.exe -version
Cdrecord-ProDVD-ProBD-Clone 2.01.01a37 (i686-pc-cygwin) Copyright (C)
1995-2008 Jörg Schilling

$ cdrecord.exe -scanbus
Cdrecord-ProDVD-ProBD-Clone 2.01.01a37 (i686-pc-cygwin) Copyright (C)
1995-2008 Jörg Schilling
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) 'HTS54104' '0G9AT00 ' 'MB2I' Disk
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) HOST ADAPTOR
scsibus1:
1,0,0 100) *
1,1,0 101) *
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) HOST ADAPTOR
scsibus2:
2,0,0 200) 'LITE-ON ' 'DVDRW SHM-165P6S' 'MS0K' Removable CD-
ROM
2,1,0 201) *
2,2,0 202) *
2,3,0 203) *
2,4,0 204) *
2,5,0 205) *
2,6,0 206) *
2,7,0 207) HOST ADAPTOR

$ cdrecord.exe -v dev=2,0,0 gracetime=5 -eject -dummy -sao tsize=0s
driveropts=burnfree,noforcespeed -pad -data foo.iso
Cdrecord-ProDVD-ProBD-Clone 2.01.01a37 (i686-pc-cygwin) Copyright (C)
1995-2008 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
Using libscg version 'schily-0.9'.
Driveropts: 'burnfree,noforcespeed'
SCSI buffer size: 64512
atapi: -1
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'LITE-ON '
Identifikation : 'DVDRW SHM-165P6S'
Revision : 'MS0K'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-R sequential recording
Profile: DVD+R/DL
Profile: DVD+R
Profile: DVD+RW
Profile: DVD-R/DL layer jump recording
Profile: DVD-R/DL sequential recording
Profile: DVD-RW sequential recording
Profile: DVD-RW restricted overwrite
Profile: DVD-RAM
Profile: DVD-R sequential recording (current)
Profile: DVD-ROM
Profile: CD-RW
Profile: CD-R
Profile: CD-ROM
Profile: Removable Disk
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE FORCESPEED
Supported modes: PACKET SAO LAYER_JUMP
Drive buf size : 1182464 = 1154 KB
FIFO size : 4194304 = 4096 KB
Track 01: data 0 MB padsize: 30 KB
Total size: 0 MB = 300 sectors
Current Secsize: 2048
WARNING: Phys disk size 2298496 differs from rzone size 2297888!
Prerecorded disk?
WARNING: Phys start: 196608 Phys end 2495103
Blocks total: 2297888 Blocks current: 2297888 Blocks remaining:
2297588
Forcespeed is OFF.
Starting to write CD/DVD/BD at speed 16 in dummy SAO mode for single
session.
Last chance to quit, starting dummy write 0 seconds. Operation
starts.
Waiting for reader process to fill input buffer ... input buffer
ready.
BURN-Free is ON.
Starting new track at sector: 0
Track 01: 0 MB written.
Track 01: writing 600 KB of pad data.
cdrecord: Input/Output error. write_g1: scsi sendcmd: no error
CDB: 2A 00 00 00 00 00 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 02 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.010s timeout 100s
write track pad data: error after 0 bytes
BFree: 1154 K BSize: 1154 K
Track 01: Total bytes read/written: 63488/0 (0 sectors).
Writing time: 0.050s
Average write speed 14.8x.
Fixating...
Fixating time: 0.031s
BURN-Free was not used.
cdrecord: fifo had 1 puts and 1 gets.
cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%.

In article <521612cf-1fc2-45e6-911e-bcb41c7d3808@s37g2000prg.googlegroups.com>,
jhc0033@gmail.com <jhc0033@gmail.com> wrote:
>On Feb 11, 1:32 pm, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
>
>> If you are on *BSD,
>
>Cygwin (I mentioned this in my original message)

If you are on Cygwin, why do you ask in a Linux/FreeBSD group?

BTW: The make clone called "GNU make" is also available as "make"
on Cygwin and GNU make unfortunately has a non-compliant makefile
parser. GNU make does not handle backslashes ('\\') and spaces (' ')
correctly in makefiles. As a result, it does not work "reliable"
on DOS alike platforms. This is another reason, why I recommend to use
"smake" instead of GNU make.



>$ mkisofs -gui -iso-level 4 -J -joliet-long -r -o foo.iso /usr/local/
>bin/cdrecord.exe
>Warning: Creating ISO-9660:1999 (version 2) filesystem.
>Warning: ISO-9660 filenames longer than 31 may cause buffer overflows
>in the OS.
>Total translation table size: 0
>Total rockridge attributes bytes: 277
>Total directory bytes: 0
>Path table size(bytes): 10
>Max brk space used 20000
>404 extents written (0 MB)
>
>$ /bin/ls -l foo.iso
>-rw-r--r-- 1 jhc None 827392 Feb 11 23:13 foo.iso

This is 404 sectors!

>$ cdrecord.exe -v dev=3D2,0,0 gracetime=3D5 -eject -dummy -sao tsize=3D0s
>driveropts=3Dburnfree,noforcespeed -pad -data foo.iso
>Cdrecord-ProDVD-ProBD-Clone 2.01.01a37 (i686-pc-cygwin) Copyright (C)
>1995-2008 J=F6rg Schilling
>TOC Type: 1 =3D CD-ROM
>scsidev: '2,0,0'

UNIX commands behave "Garbage in -> Garbage out"

If you tell cdecord to so nonsense, it will to nonsense.

You told it to write 0 sectors of data, why did you do this?

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

On Wed, 13 Feb 2008 17:37:48 UTC, js@cs.tu-berlin.de (Joerg Schilling)
wrote:

> In article <521612cf-1fc2-45e6-911e-bcb41c7d3808@s37g2000prg.googlegroups.com>,
> jhc0033@gmail.com <jhc0033@gmail.com> wrote:
> >On Feb 11, 1:32 pm, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
> >
> >> If you are on *BSD,
> >
> >Cygwin (I mentioned this in my original message)
>
> If you are on Cygwin, why do you ask in a Linux/FreeBSD group?

You should read the whole thread. The original post said:

"(Technically, I'm using mkisofs and cdrecord compiled for Cygwin, but
I think there's a better chance of getting an answer here, because
mkisofs and cdrecord are popular tools on *NIX, and my question is
about their usage, not the OS)"

--
Bob Eager
UNIX since v6..
http://tinyurl.com/2xqr6h

On Feb 13, 9:37 am, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
> In article <521612cf-1fc2-45e6-911e-bcb41c7d3...@s37g2000prg.googlegroups.com>,
>
> jhc0...@gmail.com <jhc0...@gmail.com> wrote:
> >On Feb 11, 1:32 pm, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
>
> >> If you are on *BSD,
>
> >Cygwin (I mentioned this in my original message)
>
> If you are on Cygwin, why do you ask in a Linux/FreeBSD group?

I had explained it there as well.

> BTW: The make clone called "GNU make" is also available as "make"
> on Cygwin and GNU make unfortunately has a non-compliant makefile
> parser. GNU make does not handle backslashes ('\\') and spaces (' ')
> correctly in makefiles. As a result, it does not work "reliable"
> on DOS alike platforms. This is another reason, why I recommend to use
> "smake" instead of GNU make.

This may be of some theoretical importance, but why would you put
backslashes and spaces in your makefiles?

> >$ cdrecord.exe -v dev=3D2,0,0 gracetime=3D5 -eject -dummy -sao tsize=3D0s
> >driveropts=3Dburnfree,noforcespeed -pad -data foo.iso

I think you are misquoting me - I have no "3D"s everywhere. I'll try
without "tsize" later - that was a mistake.

However...

> You told it to write 0 sectors of data, why did you do this?

Why didn't cdrecord handle that correctly? I told it to write 0
sectors, but instead it performed an illegal request and tried to
write to an invalid address.

If I ask you to give me zero apples, why do you try to strangle an
ostrich, so to speak? Your perfectionism only applies to others?

"jhc0033@gmail.com" <jhc0033@gmail.com> writes:

>On Feb 13, 9:37 am, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
>> In article <521612cf-1fc2-45e6-911e-bcb41c7d3...@s37g2000prg.googlegroups.com>,
>>
>> jhc0...@gmail.com <jhc0...@gmail.com> wrote:
>> >On Feb 11, 1:32 pm, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
>>
>> >> If you are on *BSD,
>>
>> >Cygwin (I mentioned this in my original message)
>>
>> If you are on Cygwin, why do you ask in a Linux/FreeBSD group?

>I had explained it there as well.

>> BTW: The make clone called "GNU make" is also available as "make"
>> on Cygwin and GNU make unfortunately has a non-compliant makefile
>> parser. GNU make does not handle backslashes ('\\') and spaces (' ')
>> correctly in makefiles. As a result, it does not work "reliable"
>> on DOS alike platforms. This is another reason, why I recommend to use
>> "smake" instead of GNU make.

>This may be of some theoretical importance, but why would you put
>backslashes and spaces in your makefiles?

He does. As always he does things differently.
Of course under Win, \ is the subdirectory separator.


>> >$ cdrecord.exe -v dev=3D2,0,0 gracetime=3D5 -eject -dummy -sao tsize=3D0s
>> >driveropts=3Dburnfree,noforcespeed -pad -data foo.iso

>I think you are misquoting me - I have no "3D"s everywhere. I'll try
>without "tsize" later - that was a mistake.

Those 3D are almost certainly some weird unicode for spaces or something
like that.
It was the tsize he was concerned about.



>However...

>> You told it to write 0 sectors of data, why did you do this?

>Why didn't cdrecord handle that correctly? I told it to write 0
>sectors, but instead it performed an illegal request and tried to
>write to an invalid address.


>If I ask you to give me zero apples, why do you try to strangle an
>ostrich, so to speak? Your perfectionism only applies to others?

In article <294c536b-04cf-4edb-8de7-2dd9bc59c6e9@l16g2000hsh.googlegroups.com>,
jhc0033@gmail.com <jhc0033@gmail.com> wrote:
>On Feb 13, 9:37 am, j...@cs.tu-berlin.de (Joerg Schilling) wrote:

>> BTW: The make clone called "GNU make" is also available as "make"
>> on Cygwin and GNU make unfortunately has a non-compliant makefile
>> parser. GNU make does not handle backslashes ('\\') and spaces (' ')
>> correctly in makefiles. As a result, it does not work "reliable"
>> on DOS alike platforms. This is another reason, why I recommend to use
>> "smake" instead of GNU make.
>
>This may be of some theoretical importance, but why would you put
>backslashes and spaces in your makefiles?

I don't put backslashes into makefiles and you most likely don't to it,
but GCC does it on Cygwin!

GNU make is incompatible to GCC on Cygwin because GNU make does
not follow the POSIX standard for space and backslash treatment.
Smake does this correct. Does this help to understand why I recommend
to use smake?

>> >$ cdrecord.exe -v dev=3D2,0,0 gracetime=3D5 -eject -dummy -sao tsize=3D0s
>> >driveropts=3Dburnfree,noforcespeed -pad -data foo.iso
>
>I think you are misquoting me - I have no "3D"s everywhere. I'll try
>without "tsize" later - that was a mistake.

This is what your newsreader put into your posting.... it is some
escape sequence for

tsize=0s

>However...
>
>> You told it to write 0 sectors of data, why did you do this?
>
>Why didn't cdrecord handle that correctly? I told it to write 0
>sectors, but instead it performed an illegal request and tried to
>write to an invalid address.

cdrecord did what you tell it:

1) it first wrote 0 sectors from the file

2) it then appended 300 sectors of pad data

For completeness, I have to check what happened later but this is
irrelevent for your problem as cdrecord correctly writes the medium if you
call it with correct parameters.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily