Re: [Bashburn-info] Copy Data CD to CD Issues

[Steven W. O. <st...@sy...>]

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