Thread: [Bashburn-info] Copy Data CD to CD Issues
Brought to you by:
bashburn
From: Nick W. <ni...@li...> - 2008-10-01 09:26:34
|
I don't know what to do about this. First issue, if you do not mount the data CD to be copied (like I just forgot to do), the copy command gets 'ignored' and the burn sequence then proceeds anyway. Next, I tried again with a mounted data CD. This time the data is ripped to *.iso in burn directory - BUT when completed, we are asked to insert blank CD to copy to. Well, you can't unless you go to another terminal and umount the original data CD first. But if you mess about like this, it does work. I honestly don't know what to do here? Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-10-01 13:36:34
|
On Wednesday, Oct 1st 2008 at 05:26 -0000, quoth Nick Warne: => =>I don't know what to do about this. First issue, if you do not mount =>the data CD to be copied (like I just forgot to do), the copy command =>gets 'ignored' and the burn sequence then proceeds anyway. => =>Next, I tried again with a mounted data CD. This time the data is =>ripped to *.iso in burn directory - BUT when completed, we are asked to =>insert blank CD to copy to. Well, you can't unless you go to another =>terminal and umount the original data CD first. => =>But if you mess about like this, it does work. => =>I honestly don't know what to do here? My time is limited here at work, but I can guess what's happening. * The copy command is using globbing. Globbing is evil. We need to only copy files that are explicitly specified. If you copy by saying something like... cp dir/* somewhere/ Then there's no way to detect that the cp didn't pick something up. We have to either verify that the disk is mounted and/or we have to always specify explict files. DEATH TO GLOBBING. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Fabian S. <fa...@sc...> - 2008-10-01 13:54:14
|
Steven W. Orr wrote: > * The copy command is using globbing. Globbing is evil. We need to only > copy files that are explicitly specified. If you copy by saying something > like... > The shell is globbing. cp will never do it. It's the shell. The globbing can be avoided easily by using single quotation marks. > cp dir/* somewhere/ > > Then there's no way to detect that the cp didn't pick something up. We > have to either verify that the disk is mounted and/or we have to always > specify explict files. DEATH TO GLOBBING. > > Of course you can detect if cd "didn't pick something up". cd will pick every file supplied as a command line argument before the last (target). if someting goes wrong the return value/exit code of cd will not be 0. the shell does the globbing, thus instead of 'dir/*', 'dir/a' 'dir/b' is supplied to cp as command line argument if 'dir/a' and 'dir/b' exist. If you do something like 'cp dir/* somewhere/' you will get an error if 'dir/' is empty. This is because if 'dir/' is empty the shell will not do globbing for the asterisk. So cp will complain that it can't find the file 'dir/*'. I think before doing major changes here...maybe somebody just forgot to check $? after the cp invocation. Just my 2 cents, Fabian |
From: Steven W. O. <st...@sy...> - 2008-10-01 14:59:57
|
On Wednesday, Oct 1st 2008 at 09:53 -0000, quoth Fabian Stietzel: =>Steven W. Orr wrote: =>> * The copy command is using globbing. Globbing is evil. We need to only =>> copy files that are explicitly specified. If you copy by saying something =>> like... =>> =>The shell is globbing. cp will never do it. It's the shell. The globbing =>can be avoided easily by using single quotation marks. => =>> cp dir/* somewhere/ =>> =>> Then there's no way to detect that the cp didn't pick something up. We =>> have to either verify that the disk is mounted and/or we have to always =>> specify explict files. DEATH TO GLOBBING. =>> =>> =>Of course you can detect if cd "didn't pick something up". cd will pick =>every file supplied as a command line argument before the last (target). =>if someting goes wrong the return value/exit code of cd will not be 0. =>the shell does the globbing, thus instead of 'dir/*', 'dir/a' 'dir/b' is =>supplied to cp as command line argument if 'dir/a' and 'dir/b' exist. => =>If you do something like 'cp dir/* somewhere/' you will get an error if =>'dir/' is empty. This is because if 'dir/' is empty the shell will not =>do globbing for the asterisk. So cp will complain that it can't find the =>file 'dir/*'. I think before doing major changes here...maybe somebody =>just forgot to check $? after the cp invocation. => => =>Just my 2 cents, =>Fabian Thanks Fabian. Certainly worth checking. Nick, do you know what code we're talking about here? Where is this cp command in question? -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Nick W. <ni...@li...> - 2008-10-01 19:01:18
|
On Wed, 1 Oct 2008 10:59:49 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Wednesday, Oct 1st 2008 at 09:53 -0000, quoth Fabian Stietzel: > > =>Steven W. Orr wrote: > =>> * The copy command is using globbing. Globbing is evil. We need > to only =>> copy files that are explicitly specified. If you copy by > saying something =>> like... > =>> > =>The shell is globbing. cp will never do it. It's the shell. The > globbing =>can be avoided easily by using single quotation marks. > => > =>> cp dir/* somewhere/ > =>> > =>> Then there's no way to detect that the cp didn't pick something > up. We =>> have to either verify that the disk is mounted and/or we > have to always =>> specify explict files. DEATH TO GLOBBING. > =>> > =>> > =>Of course you can detect if cd "didn't pick something up". cd will > pick =>every file supplied as a command line argument before the last > (target). =>if someting goes wrong the return value/exit code of cd > will not be 0. =>the shell does the globbing, thus instead of > 'dir/*', 'dir/a' 'dir/b' is =>supplied to cp as command line argument > if 'dir/a' and 'dir/b' exist. => > =>If you do something like 'cp dir/* somewhere/' you will get an > error if =>'dir/' is empty. This is because if 'dir/' is empty the > shell will not =>do globbing for the asterisk. So cp will complain > that it can't find the =>file 'dir/*'. I think before doing major > changes here...maybe somebody =>just forgot to check $? after the cp > invocation. => > => > =>Just my 2 cents, > =>Fabian > > Thanks Fabian. Certainly worth checking. Nick, do you know what code > we're talking about here? Where is this cp command in question? > No, I didn't analyse it at all. 1) Copy Data CD (CD to CD) is where this issue is. I haven't looked at code at due to testing all the other stuff. Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-10-01 19:41:52
|
On Wednesday, Oct 1st 2008 at 15:01 -0000, quoth Nick Warne: =>On Wed, 1 Oct 2008 10:59:49 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> On Wednesday, Oct 1st 2008 at 09:53 -0000, quoth Fabian Stietzel: =>> =>> =>Steven W. Orr wrote: =>> =>> * The copy command is using globbing. Globbing is evil. We need =>> to only =>> copy files that are explicitly specified. If you copy by =>> saying something =>> like... =>> =>> =>> =>The shell is globbing. cp will never do it. It's the shell. The =>> globbing =>can be avoided easily by using single quotation marks. =>> => =>> =>> cp dir/* somewhere/ =>> =>> =>> =>> Then there's no way to detect that the cp didn't pick something =>> up. We =>> have to either verify that the disk is mounted and/or we =>> have to always =>> specify explict files. DEATH TO GLOBBING. =>> =>> =>> =>> =>> =>Of course you can detect if cd "didn't pick something up". cd will =>> pick =>every file supplied as a command line argument before the last =>> (target). =>if someting goes wrong the return value/exit code of cd =>> will not be 0. =>the shell does the globbing, thus instead of =>> 'dir/*', 'dir/a' 'dir/b' is =>supplied to cp as command line argument =>> if 'dir/a' and 'dir/b' exist. => =>> =>If you do something like 'cp dir/* somewhere/' you will get an =>> error if =>'dir/' is empty. This is because if 'dir/' is empty the =>> shell will not =>do globbing for the asterisk. So cp will complain =>> that it can't find the =>file 'dir/*'. I think before doing major =>> changes here...maybe somebody =>just forgot to check $? after the cp =>> invocation. => =>> => =>> =>Just my 2 cents, =>> =>Fabian =>> =>> Thanks Fabian. Certainly worth checking. Nick, do you know what code =>> we're talking about here? Where is this cp command in question? =>> => =>No, I didn't analyse it at all. => =>1) Copy Data CD (CD to CD) => =>is where this issue is. I haven't looked at code at due to testing all =>the other stuff. I just looked at the code and it looks funny (not ha ha funny). What we're basically doing, I think, is this: mkisofs | cdrecord which is probably ok. But what's coded is this: mkisofs -o fn.iso | cdrecord fn.iso If cdrecord gets a filename arg on the commandline then it's not going to read from its pipe. Same for mkisofs: -o filename is the name of the file to which the iso9660 filesystem image should be written. This can be a disk file, a tape drive, or it can correspond directly to the device name of the optical disc writer. If not specified, stdout is used. Note that the output can also be a block special device for a regular disk drive, in which case the disk partition can be mounted and examined to ensure that the premastering was done correctly. The last person to put his dirty mitss on this module before I hacked on it was (drum roll please) Anders on rev 388. Anders, can you look at this one? What we currently have is this mkfifo BBCDCOPY ${BB_READCD} ${BB_READ_OPTS} -o ${BBBURNDIR}/BashBurn.iso \ ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} ${BBDTAO} \ -v -data -eject ${BBBURNDIR}/BashBurn.iso echo $bb_dm_ch2_5 rm ${BBBURNDIR}/BashBurn.iso and I think it should be this ${BB_READCD} ${BB_READ_OPTS} \ ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} ${BBDTAO} \ -v -data -eject echo $bb_dm_ch2_5 Also note that the mkfifo and the rm should be removed. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
From: Anders L. <and...@gm...> - 2008-10-01 20:25:56
|
ons 2008-10-01 klockan 15:41 -0400 skrev Steven W. Orr: > On Wednesday, Oct 1st 2008 at 15:01 -0000, quoth Nick Warne: > > =>On Wed, 1 Oct 2008 10:59:49 -0400 (EDT) > =>"Steven W. Orr" <st...@sy...> wrote: > => > =>> On Wednesday, Oct 1st 2008 at 09:53 -0000, quoth Fabian Stietzel: > =>> > =>> =>Steven W. Orr wrote: > =>> =>> * The copy command is using globbing. Globbing is evil. We need > =>> to only =>> copy files that are explicitly specified. If you copy by > =>> saying something =>> like... > =>> =>> > =>> =>The shell is globbing. cp will never do it. It's the shell. The > =>> globbing =>can be avoided easily by using single quotation marks. > =>> => > =>> =>> cp dir/* somewhere/ > =>> =>> > =>> =>> Then there's no way to detect that the cp didn't pick something > =>> up. We =>> have to either verify that the disk is mounted and/or we > =>> have to always =>> specify explict files. DEATH TO GLOBBING. > =>> =>> > =>> =>> > =>> =>Of course you can detect if cd "didn't pick something up". cd will > =>> pick =>every file supplied as a command line argument before the last > =>> (target). =>if someting goes wrong the return value/exit code of cd > =>> will not be 0. =>the shell does the globbing, thus instead of > =>> 'dir/*', 'dir/a' 'dir/b' is =>supplied to cp as command line argument > =>> if 'dir/a' and 'dir/b' exist. => > =>> =>If you do something like 'cp dir/* somewhere/' you will get an > =>> error if =>'dir/' is empty. This is because if 'dir/' is empty the > =>> shell will not =>do globbing for the asterisk. So cp will complain > =>> that it can't find the =>file 'dir/*'. I think before doing major > =>> changes here...maybe somebody =>just forgot to check $? after the cp > =>> invocation. => > =>> => > =>> =>Just my 2 cents, > =>> =>Fabian > =>> > =>> Thanks Fabian. Certainly worth checking. Nick, do you know what code > =>> we're talking about here? Where is this cp command in question? > =>> > => > =>No, I didn't analyse it at all. > => > =>1) Copy Data CD (CD to CD) > => > =>is where this issue is. I haven't looked at code at due to testing all > =>the other stuff. > > I just looked at the code and it looks funny (not ha ha funny). What we're > basically doing, I think, is this: > > mkisofs | cdrecord > > which is probably ok. But what's coded is this: > > mkisofs -o fn.iso | cdrecord fn.iso > > If cdrecord gets a filename arg on the commandline then it's not going to > read from its pipe. Same for mkisofs: > > -o filename > is the name of the file to which the iso9660 filesystem image > should be written. This can be a disk file, a tape drive, or it > can correspond directly to the device name of the optical disc > writer. If not specified, stdout is used. Note that the output > can also be a block special device for a regular disk drive, in > which case the disk partition can be mounted and examined to > ensure that the premastering was done correctly. > > The last person to put his dirty mitss on this module before I hacked on > it was (drum roll please) Anders on rev 388. Anders, can you look at this > one? What we currently have is this > > mkfifo BBCDCOPY > ${BB_READCD} ${BB_READ_OPTS} -o ${BBBURNDIR}/BashBurn.iso \ > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} ${BBDTAO} \ > -v -data -eject ${BBBURNDIR}/BashBurn.iso > echo $bb_dm_ch2_5 > rm ${BBBURNDIR}/BashBurn.iso > > and I think it should be this > > ${BB_READCD} ${BB_READ_OPTS} \ > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} ${BBDTAO} \ > -v -data -eject > echo $bb_dm_ch2_5 > > Also note that the mkfifo and the rm should be removed. > I did that? Bad me. Your fix looks correct to me. -- Anders Lindén http://bashburn.sf.net |
From: Nick W. <ni...@li...> - 2008-10-02 08:08:43
|
On Wed, 1 Oct 2008 15:41:41 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > =>No, I didn't analyse it at all. > => > =>1) Copy Data CD (CD to CD) > => > =>is where this issue is. I haven't looked at code at due to testing > all =>the other stuff. > > I just looked at the code and it looks funny (not ha ha funny). What > we're basically doing, I think, is this: > > mkisofs | cdrecord > > which is probably ok. But what's coded is this: > > mkisofs -o fn.iso | cdrecord fn.iso > > If cdrecord gets a filename arg on the commandline then it's not > going to read from its pipe. Same for mkisofs: > > -o filename > is the name of the file to which the iso9660 > filesystem image should be written. This can be a disk file, a tape > drive, or it can correspond directly to the device name of the > optical disc writer. If not specified, stdout is used. Note that > the output can also be a block special device for a regular disk > drive, in which case the disk partition can be mounted and > examined to ensure that the premastering was done correctly. > > The last person to put his dirty mitss on this module before I hacked > on it was (drum roll please) Anders on rev 388. Anders, can you look > at this one? What we currently have is this > > mkfifo BBCDCOPY > ${BB_READCD} ${BB_READ_OPTS} -o ${BBBURNDIR}/BashBurn.iso \ > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} > ${BBDTAO} \ -v -data -eject ${BBBURNDIR}/BashBurn.iso > echo $bb_dm_ch2_5 > rm ${BBBURNDIR}/BashBurn.iso > > and I think it should be this > > ${BB_READCD} ${BB_READ_OPTS} \ > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} > ${BBDTAO} \ -v -data -eject > echo $bb_dm_ch2_5 > > Also note that the mkfifo and the rm should be removed. OK, this isn't what I was talking about. This is what needs to happen. Test there is a data disc mounted/there is data in the mount point (otherwise it carries on and tries to burn nothing). After the data has been burnt to disc, umount the disc before asking user to insert a blank CD. Nick -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@li...> - 2008-10-02 09:28:09
|
On Thu, 2 Oct 2008 09:08:26 +0100 Nick Warne <ni...@li...> wrote: > On Wed, 1 Oct 2008 15:41:41 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > > > =>No, I didn't analyse it at all. > > => > > =>1) Copy Data CD (CD to CD) > > => > > =>is where this issue is. I haven't looked at code at due to > > testing all =>the other stuff. > > > > I just looked at the code and it looks funny (not ha ha funny). What > > we're basically doing, I think, is this: > > > > mkisofs | cdrecord > > > > which is probably ok. But what's coded is this: > > > > mkisofs -o fn.iso | cdrecord fn.iso > > > > If cdrecord gets a filename arg on the commandline then it's not > > going to read from its pipe. Same for mkisofs: > > > > -o filename > > is the name of the file to which the iso9660 > > filesystem image should be written. This can be a disk file, a tape > > drive, or it can correspond directly to the device name of the > > optical disc writer. If not specified, stdout is used. Note that > > the output can also be a block special device for a regular disk > > drive, in which case the disk partition can be mounted and > > examined to ensure that the premastering was done correctly. > > > > The last person to put his dirty mitss on this module before I > > hacked on it was (drum roll please) Anders on rev 388. Anders, can > > you look at this one? What we currently have is this > > > > mkfifo BBCDCOPY > > ${BB_READCD} ${BB_READ_OPTS} -o ${BBBURNDIR}/BashBurn.iso \ > > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} > > ${BBDTAO} \ -v -data -eject ${BBBURNDIR}/BashBurn.iso > > echo $bb_dm_ch2_5 > > rm ${BBBURNDIR}/BashBurn.iso > > > > and I think it should be this > > > > ${BB_READCD} ${BB_READ_OPTS} \ > > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} > > ${BBDTAO} \ -v -data -eject > > echo $bb_dm_ch2_5 > > > > Also note that the mkfifo and the rm should be removed. > > OK, this isn't what I was talking about. > > This is what needs to happen. > > Test there is a data disc mounted/there is data in the mount point > (otherwise it carries on and tries to burn nothing). > > After the data has been burnt to disc, umount the disc before asking > user to insert a blank CD. OK, I have attempted to fix that up. It is a bit hairy, but I don't know what else to do. I check if the device mount point $BBCDMNT is mounted Then later umount it, eject, before we get asked to put in a blank CD. This, of course, will all fail if the device is wrong, or if it is mounted elsewhere. But its better than what we had. Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-10-02 16:15:56
|
On Thursday, Oct 2nd 2008 at 05:27 -0000, quoth Nick Warne: =>On Thu, 2 Oct 2008 09:08:26 +0100 =>Nick Warne <ni...@li...> wrote: => =>> On Wed, 1 Oct 2008 15:41:41 -0400 (EDT) =>> "Steven W. Orr" <st...@sy...> wrote: =>> =>> =>> > =>No, I didn't analyse it at all. =>> > => =>> > =>1) Copy Data CD (CD to CD) =>> > => =>> > =>is where this issue is. I haven't looked at code at due to =>> > testing all =>the other stuff. =>> > =>> > I just looked at the code and it looks funny (not ha ha funny). What =>> > we're basically doing, I think, is this: =>> > =>> > mkisofs | cdrecord =>> > =>> > which is probably ok. But what's coded is this: =>> > =>> > mkisofs -o fn.iso | cdrecord fn.iso =>> > =>> > If cdrecord gets a filename arg on the commandline then it's not =>> > going to read from its pipe. Same for mkisofs: =>> > =>> > -o filename =>> > is the name of the file to which the iso9660 =>> > filesystem image should be written. This can be a disk file, a tape =>> > drive, or it can correspond directly to the device name of the =>> > optical disc writer. If not specified, stdout is used. Note that =>> > the output can also be a block special device for a regular disk =>> > drive, in which case the disk partition can be mounted and =>> > examined to ensure that the premastering was done correctly. =>> > =>> > The last person to put his dirty mitss on this module before I =>> > hacked on it was (drum roll please) Anders on rev 388. Anders, can =>> > you look at this one? What we currently have is this =>> > =>> > mkfifo BBCDCOPY =>> > ${BB_READCD} ${BB_READ_OPTS} -o ${BBBURNDIR}/BashBurn.iso \ =>> > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} =>> > ${BBDTAO} \ -v -data -eject ${BBBURNDIR}/BashBurn.iso =>> > echo $bb_dm_ch2_5 =>> > rm ${BBBURNDIR}/BashBurn.iso =>> > =>> > and I think it should be this =>> > =>> > ${BB_READCD} ${BB_READ_OPTS} \ =>> > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} =>> > ${BBDTAO} \ -v -data -eject =>> > echo $bb_dm_ch2_5 =>> > =>> > Also note that the mkfifo and the rm should be removed. =>> =>> OK, this isn't what I was talking about. =>> =>> This is what needs to happen. =>> =>> Test there is a data disc mounted/there is data in the mount point =>> (otherwise it carries on and tries to burn nothing). =>> =>> After the data has been burnt to disc, umount the disc before asking =>> user to insert a blank CD. => =>OK, I have attempted to fix that up. => =>It is a bit hairy, but I don't know what else to do. => =>I check if the device mount point $BBCDMNT is mounted =>Then later umount it, eject, before we get asked to put in a blank CD. => =>This, of course, will all fail if the device is wrong, or if it is =>mounted elsewhere. But its better than what we had. Nick, I took a poke at fixing up datafunc. It does need to be tested. Instead of mount | grep to see if the cd is mounted, just grep /etc/mtab. Also, I took out that mkisofs -o fn | cdrecord fn construct. It was the same as cat zzz | cat zzz only worse. The first cat (mkisofs) had a -o to specify an output filename. Then the second cat (cdrecord) had a filename on the commandline so it never read from the pipe. Now the data really is going through the pipe. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Nick W. <ni...@uk...> - 2008-10-02 19:14:52
|
On Thu, 2 Oct 2008 12:15:36 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > =>It is a bit hairy, but I don't know what else to do. > => > =>I check if the device mount point $BBCDMNT is mounted > =>Then later umount it, eject, before we get asked to put in a blank > CD. => > =>This, of course, will all fail if the device is wrong, or if it is > =>mounted elsewhere. But its better than what we had. > > Nick, I took a poke at fixing up datafunc. It does need to be tested. > > Instead of mount | grep to see if the cd is mounted, just > grep /etc/mtab. Also, I took out that mkisofs -o fn | cdrecord fn > construct. It was the same as cat zzz | cat zzz only worse. The first > cat (mkisofs) had a -o to specify an output filename. Then the second > cat (cdrecord) had a filename on the commandline so it never read > from the pipe. Now the data really is going through the pipe. OK, I will test tomorrow. Football soon, Pompey in Europe: http://news.bbc.co.uk/sport1/low/football/europe/7639445.stm Also I now have about 395 'Best of Thin Lizzy' CD's and around 125 'Deep Purple Machine Head' Cd's.... lol Nick -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@li...> - 2008-10-02 19:41:07
|
On Thu, 2 Oct 2008 12:15:36 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Thursday, Oct 2nd 2008 at 05:27 -0000, quoth Nick Warne: > > =>On Thu, 2 Oct 2008 09:08:26 +0100 > =>Nick Warne <ni...@li...> wrote: > => > =>> On Wed, 1 Oct 2008 15:41:41 -0400 (EDT) > =>> "Steven W. Orr" <st...@sy...> wrote: > =>> > =>> > =>> > =>No, I didn't analyse it at all. > =>> > => > =>> > =>1) Copy Data CD (CD to CD) > =>> > => > =>> > =>is where this issue is. I haven't looked at code at due to > =>> > testing all =>the other stuff. > =>> > > =>> > I just looked at the code and it looks funny (not ha ha funny). > What =>> > we're basically doing, I think, is this: > =>> > > =>> > mkisofs | cdrecord > =>> > > =>> > which is probably ok. But what's coded is this: > =>> > > =>> > mkisofs -o fn.iso | cdrecord fn.iso > =>> > > =>> > If cdrecord gets a filename arg on the commandline then it's not > =>> > going to read from its pipe. Same for mkisofs: > =>> > > =>> > -o filename > =>> > is the name of the file to which the iso9660 > =>> > filesystem image should be written. This can be a disk file, a > tape =>> > drive, or it can correspond directly to the device name > of the =>> > optical disc writer. If not specified, stdout is used. > Note that =>> > the output can also be a block special device for a > regular disk =>> > drive, in which case the disk partition can be > mounted and =>> > examined to ensure that the premastering was done > correctly. =>> > > =>> > The last person to put his dirty mitss on this module before I > =>> > hacked on it was (drum roll please) Anders on rev 388. Anders, > can =>> > you look at this one? What we currently have is this > =>> > > =>> > mkfifo BBCDCOPY > =>> > ${BB_READCD} ${BB_READ_OPTS} -o > ${BBBURNDIR}/BashBurn.iso \ =>> > ${BBCDMNT} | > ${BB_CDBURNCMD} dev=${BBCDWRITER} =>> > ${BBDTAO} \ -v -data -eject > ${BBBURNDIR}/BashBurn.iso =>> > echo $bb_dm_ch2_5 > =>> > rm ${BBBURNDIR}/BashBurn.iso > =>> > > =>> > and I think it should be this > =>> > > =>> > ${BB_READCD} ${BB_READ_OPTS} \ > =>> > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} > =>> > ${BBDTAO} \ -v -data -eject > =>> > echo $bb_dm_ch2_5 > =>> > > =>> > Also note that the mkfifo and the rm should be removed. > =>> > =>> OK, this isn't what I was talking about. > =>> > =>> This is what needs to happen. > =>> > =>> Test there is a data disc mounted/there is data in the mount point > =>> (otherwise it carries on and tries to burn nothing). > =>> > =>> After the data has been burnt to disc, umount the disc before > asking =>> user to insert a blank CD. > => > =>OK, I have attempted to fix that up. > => > =>It is a bit hairy, but I don't know what else to do. > => > =>I check if the device mount point $BBCDMNT is mounted > =>Then later umount it, eject, before we get asked to put in a blank > CD. => > =>This, of course, will all fail if the device is wrong, or if it is > =>mounted elsewhere. But its better than what we had. > > Nick, I took a poke at fixing up datafunc. It does need to be tested. > > Instead of mount | grep to see if the cd is mounted, just > grep /etc/mtab. Also, I took out that mkisofs -o fn | cdrecord fn > construct. It was the same as cat zzz | cat zzz only worse. The first > cat (mkisofs) had a -o to specify an output filename. Then the second > cat (cdrecord) had a filename on the commandline so it never read > from the pipe. Now the data really is going through the pipe. OK, this breaks real bad. Nothing happens now at all. Output below. Nick ====== |-(Data Menu) | 0) Burn Data | 1) Copy Data CD (CD to CD) | 2) Burn Data DVD | 3) Format CDRW | 4) Format DVD | 5) Back | Your Choice? [0-5] |> 1 Warning: creating filesystem that does not conform to ISO-9660. Setting input-charset to 'ISO-8859-1' from locale. Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) Copyright (C) 1995-2008 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/cdrom' devname: '/dev/cdrom' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. Linux sg driver version: 3.5.27 Using libscg version 'schily-0.9'. SCSI buffer size: 64512 atapi: 1 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identifikation : 'CDDVDW SH-S202J ' Revision : 'SB00' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: CD-R Profile: DVD-R/DL sequential recording Profile: DVD-R/DL layer jump recording Profile: DVD+R/DL Profile: DVD+R Profile: DVD+RW Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-ROM Profile: CD-RW Profile: CD-R (current) Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1962752 = 1916 KB CD copied! rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or directory -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@uk...> - 2008-10-02 19:43:30
|
On Thu, 2 Oct 2008 12:15:36 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Thursday, Oct 2nd 2008 at 05:27 -0000, quoth Nick Warne: > > =>On Thu, 2 Oct 2008 09:08:26 +0100 > =>Nick Warne <ni...@li...> wrote: > => > =>> On Wed, 1 Oct 2008 15:41:41 -0400 (EDT) > =>> "Steven W. Orr" <st...@sy...> wrote: > =>> > =>> > =>> > =>No, I didn't analyse it at all. > =>> > => > =>> > =>1) Copy Data CD (CD to CD) > =>> > => > =>> > =>is where this issue is. I haven't looked at code at due to > =>> > testing all =>the other stuff. > =>> > > =>> > I just looked at the code and it looks funny (not ha ha funny). > What =>> > we're basically doing, I think, is this: > =>> > > =>> > mkisofs | cdrecord > =>> > > =>> > which is probably ok. But what's coded is this: > =>> > > =>> > mkisofs -o fn.iso | cdrecord fn.iso > =>> > > =>> > If cdrecord gets a filename arg on the commandline then it's not > =>> > going to read from its pipe. Same for mkisofs: > =>> > > =>> > -o filename > =>> > is the name of the file to which the iso9660 > =>> > filesystem image should be written. This can be a disk file, a > tape =>> > drive, or it can correspond directly to the device name > of the =>> > optical disc writer. If not specified, stdout is used. > Note that =>> > the output can also be a block special device for a > regular disk =>> > drive, in which case the disk partition can be > mounted and =>> > examined to ensure that the premastering was done > correctly. =>> > > =>> > The last person to put his dirty mitss on this module before I > =>> > hacked on it was (drum roll please) Anders on rev 388. Anders, > can =>> > you look at this one? What we currently have is this > =>> > > =>> > mkfifo BBCDCOPY > =>> > ${BB_READCD} ${BB_READ_OPTS} -o > ${BBBURNDIR}/BashBurn.iso \ =>> > ${BBCDMNT} | > ${BB_CDBURNCMD} dev=${BBCDWRITER} =>> > ${BBDTAO} \ -v -data -eject > ${BBBURNDIR}/BashBurn.iso =>> > echo $bb_dm_ch2_5 > =>> > rm ${BBBURNDIR}/BashBurn.iso > =>> > > =>> > and I think it should be this > =>> > > =>> > ${BB_READCD} ${BB_READ_OPTS} \ > =>> > ${BBCDMNT} | ${BB_CDBURNCMD} dev=${BBCDWRITER} > =>> > ${BBDTAO} \ -v -data -eject > =>> > echo $bb_dm_ch2_5 > =>> > > =>> > Also note that the mkfifo and the rm should be removed. > =>> > =>> OK, this isn't what I was talking about. > =>> > =>> This is what needs to happen. > =>> > =>> Test there is a data disc mounted/there is data in the mount point > =>> (otherwise it carries on and tries to burn nothing). > =>> > =>> After the data has been burnt to disc, umount the disc before > asking =>> user to insert a blank CD. > => > =>OK, I have attempted to fix that up. > => > =>It is a bit hairy, but I don't know what else to do. > => > =>I check if the device mount point $BBCDMNT is mounted > =>Then later umount it, eject, before we get asked to put in a blank > CD. => > =>This, of course, will all fail if the device is wrong, or if it is > =>mounted elsewhere. But its better than what we had. > > Nick, I took a poke at fixing up datafunc. It does need to be tested. > > Instead of mount | grep to see if the cd is mounted, just > grep /etc/mtab. Also, I took out that mkisofs -o fn | cdrecord fn > construct. It was the same as cat zzz | cat zzz only worse. The first > cat (mkisofs) had a -o to specify an output filename. Then the second > cat (cdrecord) had a filename on the commandline so it never read > from the pipe. Now the data really is going through the pipe. OK, this breaks real bad. Nothing happens now at all. Output below. Nick ====== |-(Data Menu) | 0) Burn Data | 1) Copy Data CD (CD to CD) | 2) Burn Data DVD | 3) Format CDRW | 4) Format DVD | 5) Back | Your Choice? [0-5] |> 1 Warning: creating filesystem that does not conform to ISO-9660. Setting input-charset to 'ISO-8859-1' from locale. Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) Copyright (C) 1995-2008 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/cdrom' devname: '/dev/cdrom' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. Linux sg driver version: 3.5.27 Using libscg version 'schily-0.9'. SCSI buffer size: 64512 atapi: 1 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identifikation : 'CDDVDW SH-S202J ' Revision : 'SB00' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: CD-R Profile: DVD-R/DL sequential recording Profile: DVD-R/DL layer jump recording Profile: DVD+R/DL Profile: DVD+R Profile: DVD+RW Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-ROM Profile: CD-RW Profile: CD-R (current) Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1962752 = 1916 KB CD copied! rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or directory -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@uk...> - 2008-10-02 19:54:11
|
On Thu, 2 Oct 2008 20:42:56 +0100 Nick Warne <ni...@uk...> wrote: > > > > Instead of mount | grep to see if the cd is mounted, just > > grep /etc/mtab. Also, I took out that mkisofs -o fn | cdrecord fn > > construct. It was the same as cat zzz | cat zzz only worse. The > > first cat (mkisofs) had a -o to specify an output filename. Then > > the second cat (cdrecord) had a filename on the commandline so it > > never read from the pipe. Now the data really is going through the > > pipe. > > > > OK, this breaks real bad. Nothing happens now at all. > > Output below. > > Nick > > ====== > > |-(Data Menu) > | 0) Burn Data > | 1) Copy Data CD (CD to CD) > | 2) Burn Data DVD > | 3) Format CDRW > | 4) Format DVD > | 5) Back > | > Your Choice? [0-5] |> 1 > Warning: creating filesystem that does not conform to ISO-9660. > Setting input-charset to 'ISO-8859-1' from locale. > Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) Copyright > (C) 1995-2008 Jörg Schilling TOC Type: 1 = CD-ROM > scsidev: '/dev/cdrom' > devname: '/dev/cdrom' > scsibus: -2 target: -2 lun: -2 > Warning: Open by 'devname' is unintentional and not supported. > Linux sg driver version: 3.5.27 > Using libscg version 'schily-0.9'. > SCSI buffer size: 64512 > atapi: 1 > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'TSSTcorp' > Identifikation : 'CDDVDW SH-S202J ' > Revision : 'SB00' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Current: CD-R > Profile: DVD-R/DL sequential recording > Profile: DVD-R/DL layer jump recording > Profile: DVD+R/DL > Profile: DVD+R > Profile: DVD+RW > Profile: DVD-RW sequential recording > Profile: DVD-RW restricted overwrite > Profile: DVD-RAM > Profile: DVD-R sequential recording > Profile: DVD-ROM > Profile: CD-RW > Profile: CD-R (current) > Profile: CD-ROM > Profile: Removable Disk > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P > RAW/R96R Drive buf size : 1962752 = 1916 KB > CD copied! > rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or > directory Steve, I reverted some of this. As my svn log says, I rather have a working version... It is working again now. Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-10-02 20:57:12
|
On Thursday, Oct 2nd 2008 at 15:53 -0000, quoth Nick Warne: =>On Thu, 2 Oct 2008 20:42:56 +0100 =>Nick Warne <ni...@uk...> wrote: => =>> > =>> > Instead of mount | grep to see if the cd is mounted, just =>> > grep /etc/mtab. Also, I took out that mkisofs -o fn | cdrecord fn =>> > construct. It was the same as cat zzz | cat zzz only worse. The =>> > first cat (mkisofs) had a -o to specify an output filename. Then =>> > the second cat (cdrecord) had a filename on the commandline so it =>> > never read from the pipe. Now the data really is going through the =>> > pipe. =>> =>> =>> =>> OK, this breaks real bad. Nothing happens now at all. =>> =>> Output below. =>> =>> Nick =>> =>> ====== =>> =>> |-(Data Menu) =>> | 0) Burn Data =>> | 1) Copy Data CD (CD to CD) =>> | 2) Burn Data DVD =>> | 3) Format CDRW =>> | 4) Format DVD =>> | 5) Back =>> | =>> Your Choice? [0-5] |> 1 =>> Warning: creating filesystem that does not conform to ISO-9660. =>> Setting input-charset to 'ISO-8859-1' from locale. =>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) Copyright =>> (C) 1995-2008 J?rg Schilling TOC Type: 1 = CD-ROM =>> scsidev: '/dev/cdrom' =>> devname: '/dev/cdrom' =>> scsibus: -2 target: -2 lun: -2 =>> Warning: Open by 'devname' is unintentional and not supported. =>> Linux sg driver version: 3.5.27 =>> Using libscg version 'schily-0.9'. =>> SCSI buffer size: 64512 =>> atapi: 1 =>> Device type : Removable CD-ROM =>> Version : 0 =>> Response Format: 2 =>> Capabilities : =>> Vendor_info : 'TSSTcorp' =>> Identifikation : 'CDDVDW SH-S202J ' =>> Revision : 'SB00' =>> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. =>> Current: CD-R =>> Profile: DVD-R/DL sequential recording =>> Profile: DVD-R/DL layer jump recording =>> Profile: DVD+R/DL =>> Profile: DVD+R =>> Profile: DVD+RW =>> Profile: DVD-RW sequential recording =>> Profile: DVD-RW restricted overwrite =>> Profile: DVD-RAM =>> Profile: DVD-R sequential recording =>> Profile: DVD-ROM =>> Profile: CD-RW =>> Profile: CD-R (current) =>> Profile: CD-ROM =>> Profile: Removable Disk =>> Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). =>> Driver flags : MMC-3 SWABAUDIO BURNFREE =>> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P =>> RAW/R96R Drive buf size : 1962752 = 1916 KB =>> CD copied! =>> rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or =>> directory => =>Steve, I reverted some of this. As my svn log says, I rather have a =>working version... => =>It is working again now. Nuts. I'll look at it. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Steven W. O. <st...@sy...> - 2008-10-02 21:09:48
|
On Thursday, Oct 2nd 2008 at 15:53 -0000, quoth Nick Warne: =>> OK, this breaks real bad. Nothing happens now at all. =>> =>> Output below. =>> =>> Nick =>> =>> ====== =>> =>> |-(Data Menu) =>> | 0) Burn Data =>> | 1) Copy Data CD (CD to CD) =>> | 2) Burn Data DVD =>> | 3) Format CDRW =>> | 4) Format DVD =>> | 5) Back =>> | =>> Your Choice? [0-5] |> 1 =>> Warning: creating filesystem that does not conform to ISO-9660. =>> Setting input-charset to 'ISO-8859-1' from locale. =>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) Copyright =>> (C) 1995-2008 J?rg Schilling TOC Type: 1 = CD-ROM =>> scsidev: '/dev/cdrom' =>> devname: '/dev/cdrom' =>> scsibus: -2 target: -2 lun: -2 =>> Warning: Open by 'devname' is unintentional and not supported. =>> Linux sg driver version: 3.5.27 =>> Using libscg version 'schily-0.9'. =>> SCSI buffer size: 64512 =>> atapi: 1 =>> Device type : Removable CD-ROM =>> Version : 0 =>> Response Format: 2 =>> Capabilities : =>> Vendor_info : 'TSSTcorp' =>> Identifikation : 'CDDVDW SH-S202J ' =>> Revision : 'SB00' =>> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. =>> Current: CD-R =>> Profile: DVD-R/DL sequential recording =>> Profile: DVD-R/DL layer jump recording =>> Profile: DVD+R/DL =>> Profile: DVD+R =>> Profile: DVD+RW =>> Profile: DVD-RW sequential recording =>> Profile: DVD-RW restricted overwrite =>> Profile: DVD-RAM =>> Profile: DVD-R sequential recording =>> Profile: DVD-ROM =>> Profile: CD-RW =>> Profile: CD-R (current) =>> Profile: CD-ROM =>> Profile: Removable Disk =>> Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). =>> Driver flags : MMC-3 SWABAUDIO BURNFREE =>> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P =>> RAW/R96R Drive buf size : 1962752 = 1916 KB =>> CD copied! =>> rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or =>> directory => =>Steve, I reverted some of this. As my svn log says, I rather have a =>working version... => =>It is working again now. I think I found the problem. mkisofs writes to stdout if there's no -o option. That works fine. But cdrecord reads from its command line arg. If its commandline arg is - (a dash) then it reads from stdin. This should fix it. Also, in the elseif that deals with only a single reader/writer, it was only deleting the BashBurn.iso file if the burn succeeded. That is now fixed as well. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
From: Nick W. <ni...@uk...> - 2008-10-02 23:53:37
|
On Thu, 2 Oct 2008 17:05:22 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Thursday, Oct 2nd 2008 at 15:53 -0000, quoth Nick Warne: > > =>> OK, this breaks real bad. Nothing happens now at all. > =>> > =>> Output below. > =>> > =>> Nick > =>> > =>> ====== > =>> > =>> |-(Data Menu) > =>> | 0) Burn Data > =>> | 1) Copy Data CD (CD to CD) > =>> | 2) Burn Data DVD > =>> | 3) Format CDRW > =>> | 4) Format DVD > =>> | 5) Back > =>> | > =>> Your Choice? [0-5] |> 1 > =>> Warning: creating filesystem that does not conform to ISO-9660. > =>> Setting input-charset to 'ISO-8859-1' from locale. > =>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) > Copyright =>> (C) 1995-2008 J?rg Schilling TOC Type: 1 = CD-ROM > =>> scsidev: '/dev/cdrom' > =>> devname: '/dev/cdrom' > =>> scsibus: -2 target: -2 lun: -2 > =>> Warning: Open by 'devname' is unintentional and not supported. > =>> Linux sg driver version: 3.5.27 > =>> Using libscg version 'schily-0.9'. > =>> SCSI buffer size: 64512 > =>> atapi: 1 > =>> Device type : Removable CD-ROM > =>> Version : 0 > =>> Response Format: 2 > =>> Capabilities : > =>> Vendor_info : 'TSSTcorp' > =>> Identifikation : 'CDDVDW SH-S202J ' > =>> Revision : 'SB00' > =>> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > =>> Current: CD-R > =>> Profile: DVD-R/DL sequential recording > =>> Profile: DVD-R/DL layer jump recording > =>> Profile: DVD+R/DL > =>> Profile: DVD+R > =>> Profile: DVD+RW > =>> Profile: DVD-RW sequential recording > =>> Profile: DVD-RW restricted overwrite > =>> Profile: DVD-RAM > =>> Profile: DVD-R sequential recording > =>> Profile: DVD-ROM > =>> Profile: CD-RW > =>> Profile: CD-R (current) > =>> Profile: CD-ROM > =>> Profile: Removable Disk > =>> Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > =>> Driver flags : MMC-3 SWABAUDIO BURNFREE > =>> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P > =>> RAW/R96R Drive buf size : 1962752 = 1916 KB > =>> CD copied! > =>> rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or > =>> directory > => > =>Steve, I reverted some of this. As my svn log says, I rather have a > =>working version... > => > =>It is working again now. > > I think I found the problem. mkisofs writes to stdout if there's no > -o option. That works fine. But cdrecord reads from its command line > arg. If its commandline arg is - (a dash) then it reads from stdin. > This should fix it. > > Also, in the elseif that deals with only a single reader/writer, it > was only deleting the BashBurn.iso file if the burn succeeded. That > is now fixed as well. > Good stuff - seems to work fine now - but I did get a funny burn this time with stop/start breaks and a warning about underruns: Waiting for reader process to fill input buffer ... input buffer ready. BURN-Free is OFF. Performing OPC... Starting new track at sector: 0 Track 01: 5 MB written (fifo 98%) [buf 26%] 7.3x. 18.44% done, estimate finish Fri Oct 3 00:46:56 2008 Track 01: 15 MB written (fifo 96%) [buf 93%] 20.1x. 36.88% done, estimate finish Fri Oct 3 00:45:53 2008 Track 01: 25 MB written (fifo 93%) [buf 0%] 8.1x. 55.27% done, estimate finish Fri Oct 3 00:45:25 2008 Track 01: 35 MB written (fifo 93%) [buf 22%] 4.8x. 73.71% done, estimate finish Fri Oct 3 00:45:15 2008 Track 01: 45 MB written (fifo 92%) [buf 26%] 4.8x. 92.10% done, estimate finish Fri Oct 3 00:45:08 2008 Track 01: 48 MB written (fifo 100%) [buf 26%] 8.1x.Total translation table size: 0 Total rockridge attributes bytes: 305 Total directory bytes: 0 Path table size(bytes): 10 Track 01: 49 MB written (fifo 98%) [buf 45%] 9.7x.Max brk space used 0 27153 extents written (53 MB) Track 01: 53 MB written (fifo 100%) [buf 100%] 24.4x. Track 01: Total bytes read/written: 55609344/55609344 (27153 sectors). Writing time: 77.487s Min drive buffer fill was 0% Total of 7 possible drive buffer underruns predicted. Fixating... Fixating time: 19.593s cdrecord: fifo had 877 puts and 877 gets. cdrecord: fifo was 0 times empty and 235 times full, min fill was 81%. CD copied! Nick -- Free Software Foundation Associate Member 5508 |
From: Anders L. <and...@gm...> - 2008-10-03 00:13:25
|
fre 2008-10-03 klockan 00:53 +0100 skrev Nick Warne: > On Thu, 2 Oct 2008 17:05:22 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > > On Thursday, Oct 2nd 2008 at 15:53 -0000, quoth Nick Warne: > > > > =>> OK, this breaks real bad. Nothing happens now at all. > > =>> > > =>> Output below. > > =>> > > =>> Nick > > =>> > > =>> ====== > > =>> > > =>> |-(Data Menu) > > =>> | 0) Burn Data > > =>> | 1) Copy Data CD (CD to CD) > > =>> | 2) Burn Data DVD > > =>> | 3) Format CDRW > > =>> | 4) Format DVD > > =>> | 5) Back > > =>> | > > =>> Your Choice? [0-5] |> 1 > > =>> Warning: creating filesystem that does not conform to ISO-9660. > > =>> Setting input-charset to 'ISO-8859-1' from locale. > > =>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) > > Copyright =>> (C) 1995-2008 J?rg Schilling TOC Type: 1 = CD-ROM > > =>> scsidev: '/dev/cdrom' > > =>> devname: '/dev/cdrom' > > =>> scsibus: -2 target: -2 lun: -2 > > =>> Warning: Open by 'devname' is unintentional and not supported. > > =>> Linux sg driver version: 3.5.27 > > =>> Using libscg version 'schily-0.9'. > > =>> SCSI buffer size: 64512 > > =>> atapi: 1 > > =>> Device type : Removable CD-ROM > > =>> Version : 0 > > =>> Response Format: 2 > > =>> Capabilities : > > =>> Vendor_info : 'TSSTcorp' > > =>> Identifikation : 'CDDVDW SH-S202J ' > > =>> Revision : 'SB00' > > =>> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > > =>> Current: CD-R > > =>> Profile: DVD-R/DL sequential recording > > =>> Profile: DVD-R/DL layer jump recording > > =>> Profile: DVD+R/DL > > =>> Profile: DVD+R > > =>> Profile: DVD+RW > > =>> Profile: DVD-RW sequential recording > > =>> Profile: DVD-RW restricted overwrite > > =>> Profile: DVD-RAM > > =>> Profile: DVD-R sequential recording > > =>> Profile: DVD-ROM > > =>> Profile: CD-RW > > =>> Profile: CD-R (current) > > =>> Profile: CD-ROM > > =>> Profile: Removable Disk > > =>> Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > > =>> Driver flags : MMC-3 SWABAUDIO BURNFREE > > =>> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P > > =>> RAW/R96R Drive buf size : 1962752 = 1916 KB > > =>> CD copied! > > =>> rm: cannot remove `/home/nick/burn/BashBurn.iso': No such file or > > =>> directory > > => > > =>Steve, I reverted some of this. As my svn log says, I rather have a > > =>working version... > > => > > =>It is working again now. > > > > I think I found the problem. mkisofs writes to stdout if there's no > > -o option. That works fine. But cdrecord reads from its command line > > arg. If its commandline arg is - (a dash) then it reads from stdin. > > This should fix it. > > > > Also, in the elseif that deals with only a single reader/writer, it > > was only deleting the BashBurn.iso file if the burn succeeded. That > > is now fixed as well. > > > > Good stuff - seems to work fine now - but I did get a funny burn this > time with stop/start breaks and a warning about underruns: > > > Waiting for reader process to fill input buffer ... input buffer ready. > BURN-Free is OFF. > Performing OPC... > Starting new track at sector: 0 > Track 01: 5 MB written (fifo 98%) [buf 26%] 7.3x. 18.44% done, estimate finish Fri Oct 3 00:46:56 2008 > Track 01: 15 MB written (fifo 96%) [buf 93%] 20.1x. 36.88% done, estimate finish Fri Oct 3 00:45:53 2008 > Track 01: 25 MB written (fifo 93%) [buf 0%] 8.1x. 55.27% done, estimate finish Fri Oct 3 00:45:25 2008 > Track 01: 35 MB written (fifo 93%) [buf 22%] 4.8x. 73.71% done, estimate finish Fri Oct 3 00:45:15 2008 > Track 01: 45 MB written (fifo 92%) [buf 26%] 4.8x. 92.10% done, estimate finish Fri Oct 3 00:45:08 2008 > Track 01: 48 MB written (fifo 100%) [buf 26%] 8.1x.Total translation table size: 0 > Total rockridge attributes bytes: 305 > Total directory bytes: 0 > Path table size(bytes): 10 > Track 01: 49 MB written (fifo 98%) [buf 45%] 9.7x.Max brk space used 0 > 27153 extents written (53 MB) > Track 01: 53 MB written (fifo 100%) [buf 100%] 24.4x. > Track 01: Total bytes read/written: 55609344/55609344 (27153 sectors). > Writing time: 77.487s > Min drive buffer fill was 0% > Total of 7 possible drive buffer underruns predicted. > Fixating... > Fixating time: 19.593s > cdrecord: fifo had 877 puts and 877 gets. > cdrecord: fifo was 0 times empty and 235 times full, min fill was 81%. > CD copied! > > > > Nick Shouldn't be a problem. Buffer underrun protection (burnfree) is enabled automatically on all burners produced nowadays even if the burnfree driver option isn't set. It's really just there for people who for some reason want to turn it off. I guess you get those warning because a straigh CD to CD copy without creating a temporary ISO file will put a lot of load on the I/O system. -- Anders Lindén http://bashburn.sf.net |
From: Nick W. <ni...@uk...> - 2008-10-03 00:23:35
|
On Fri, 03 Oct 2008 02:13:26 +0200 Anders Lindén <and...@gm...> wrote: > fre 2008-10-03 klockan 00:53 +0100 skrev Nick Warne: > > On Thu, 2 Oct 2008 17:05:22 -0400 (EDT) > > "Steven W. Orr" <st...@sy...> wrote: > > > > > On Thursday, Oct 2nd 2008 at 15:53 -0000, quoth Nick Warne: > > > > > > =>> OK, this breaks real bad. Nothing happens now at all. > > > =>> > > > =>> Output below. > > > =>> > > > =>> Nick > > > =>> > > > =>> ====== > > > =>> > > > =>> |-(Data Menu) > > > =>> | 0) Burn Data > > > =>> | 1) Copy Data CD (CD to CD) > > > =>> | 2) Burn Data DVD > > > =>> | 3) Format CDRW > > > =>> | 4) Format DVD > > > =>> | 5) Back > > > =>> | > > > =>> Your Choice? [0-5] |> 1 > > > =>> Warning: creating filesystem that does not conform to > > > ISO-9660. =>> Setting input-charset to 'ISO-8859-1' from locale. > > > =>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) > > > Copyright =>> (C) 1995-2008 J?rg Schilling TOC Type: 1 = CD-ROM > > > =>> scsidev: '/dev/cdrom' > > > =>> devname: '/dev/cdrom' > > > =>> scsibus: -2 target: -2 lun: -2 > > > =>> Warning: Open by 'devname' is unintentional and not supported. > > > =>> Linux sg driver version: 3.5.27 > > > =>> Using libscg version 'schily-0.9'. > > > =>> SCSI buffer size: 64512 > > > =>> atapi: 1 > > > =>> Device type : Removable CD-ROM > > > =>> Version : 0 > > > =>> Response Format: 2 > > > =>> Capabilities : > > > =>> Vendor_info : 'TSSTcorp' > > > =>> Identifikation : 'CDDVDW SH-S202J ' > > > =>> Revision : 'SB00' > > > =>> Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > > > =>> Current: CD-R > > > =>> Profile: DVD-R/DL sequential recording > > > =>> Profile: DVD-R/DL layer jump recording > > > =>> Profile: DVD+R/DL > > > =>> Profile: DVD+R > > > =>> Profile: DVD+RW > > > =>> Profile: DVD-RW sequential recording > > > =>> Profile: DVD-RW restricted overwrite > > > =>> Profile: DVD-RAM > > > =>> Profile: DVD-R sequential recording > > > =>> Profile: DVD-ROM > > > =>> Profile: CD-RW > > > =>> Profile: CD-R (current) > > > =>> Profile: CD-ROM > > > =>> Profile: Removable Disk > > > =>> Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > > > =>> Driver flags : MMC-3 SWABAUDIO BURNFREE > > > =>> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 > > > RAW/R96P =>> RAW/R96R Drive buf size : 1962752 = 1916 KB > > > =>> CD copied! > > > =>> rm: cannot remove `/home/nick/burn/BashBurn.iso': No such > > > file or =>> directory > > > => > > > =>Steve, I reverted some of this. As my svn log says, I rather > > > have a =>working version... > > > => > > > =>It is working again now. > > > > > > I think I found the problem. mkisofs writes to stdout if there's > > > no -o option. That works fine. But cdrecord reads from its > > > command line arg. If its commandline arg is - (a dash) then it > > > reads from stdin. This should fix it. > > > > > > Also, in the elseif that deals with only a single reader/writer, > > > it was only deleting the BashBurn.iso file if the burn succeeded. > > > That is now fixed as well. > > > > > > > Good stuff - seems to work fine now - but I did get a funny burn > > this time with stop/start breaks and a warning about underruns: > > > > > > Waiting for reader process to fill input buffer ... input buffer > > ready. BURN-Free is OFF. > > Performing OPC... > > Starting new track at sector: 0 > > Track 01: 5 MB written (fifo 98%) [buf 26%] 7.3x. 18.44% > > done, estimate finish Fri Oct 3 00:46:56 2008 Track 01: 15 MB > > written (fifo 96%) [buf 93%] 20.1x. 36.88% done, estimate finish > > Fri Oct 3 00:45:53 2008 Track 01: 25 MB written (fifo 93%) > > [buf 0%] 8.1x. 55.27% done, estimate finish Fri Oct 3 00:45:25 > > 2008 Track 01: 35 MB written (fifo 93%) [buf 22%] 4.8x. > > 73.71% done, estimate finish Fri Oct 3 00:45:15 2008 Track 01: > > 45 MB written (fifo 92%) [buf 26%] 4.8x. 92.10% done, estimate > > finish Fri Oct 3 00:45:08 2008 Track 01: 48 MB written (fifo > > 100%) [buf 26%] 8.1x.Total translation table size: 0 Total > > rockridge attributes bytes: 305 Total directory bytes: 0 Path table > > size(bytes): 10 Track 01: 49 MB written (fifo 98%) [buf 45%] > > 9.7x.Max brk space used 0 27153 extents written (53 MB) Track 01: > > 53 MB written (fifo 100%) [buf 100%] 24.4x. Track 01: Total bytes > > read/written: 55609344/55609344 (27153 sectors). Writing time: > > 77.487s Min drive buffer fill was 0% Total of 7 possible drive > > buffer underruns predicted. Fixating... > > Fixating time: 19.593s > > cdrecord: fifo had 877 puts and 877 gets. > > cdrecord: fifo was 0 times empty and 235 times full, min fill was > > 81%. CD copied! > > > > > > > > Nick > > Shouldn't be a problem. Buffer underrun protection (burnfree) is > enabled automatically on all burners produced nowadays even if the > burnfree driver option isn't set. It's really just there for people > who for some reason want to turn it off. > I guess you get those warning because a straigh CD to CD copy without > creating a temporary ISO file will put a lot of load on the I/O > system. I see. It burnt fine though. I now have 16 'Orson Welles - Original War of the Worlds radio broadcast 1938' data CD's :-D Nick -- Free Software Foundation Associate Member 5508 |