bashburn-info — BashBurn mailing list

Re: [Bashburn-info] man page

[Nick W. <ni...@uk...>]

On Sun, 5 Oct 2008 18:20:14 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> On Sunday, Oct 5th 2008 at 12:10 -0000, quoth Nick Warne:
> 
> =>On Sun, 5 Oct 2008 10:49:34 -0400 (EDT)
> =>"Steven W. Orr" <st...@sy...> wrote:
> =>
> =>> On Sunday, Oct 5th 2008 at 05:56 -0000, quoth Nick Warne:
> =>> 
> =>> =>On Sat, 4 Oct 2008 21:53:46 -0400 (EDT)
> =>> =>"Steven W. Orr" <st...@sy...> wrote:
> =>> =>
> =>> =>> I moved bashburn.1.gz to bashburn.1
> =>> =>> 
> =>> =>> I also did a bit of hacking in the manpage structure. I'm not
> =>> great =>> at the macro usage but I did fix a few things. Let me
> know =>> if you see =>> any problems.
> =>> =>
> =>> =>Steve, you should have said.  I have a man page template, and
> the =>> =>bashburn man page gets created from that using sed wizardry
> - that =>> way =>it is easy to change anything.
> =>> =>
> =>> =>http://anaturb.net/create_man_p.htm
> =>> 
> =>> Sorry, I don't understand. Is there a template somewhere?
> =>
> =>Yes, I have a bashburn template directory, so I edit the template
> and =>then create the man page.
> =>
> =>I was wondering where it should go, as it should NOT be in the
> release =>files, so I guess it could live in trunk only just for man
> page edits, =>and just the man page itself gets moved over to release.
> =>
> =>Let me do some documentation and upload it anyway.
> 
> Now I see the problem. The content and shape of the src repository
> has nothing at all to do with the content and shape of the released
> code.
> 
> So.... If you have a script, or a body of software that should be
> executed in order to generate a man page, then the man page itself
> should not be checked into the repository at all. IOW, the file
> bashburn.1 (.gz or otherwise) is not a file that was *written* by a
> person. It's a file that was generated. (If you ever worked in the
> ClearCase world, we would call such things "derived objects".) You
> have some file which right now is sitting in Merry Old England and
> that was used as input to something which resulted in bashburn.1 . If
> you got hit by a bus then we'd be sitting on the .1 file, which
> probably isn't a huge loss (the file, not you), but we'd have no way
> to start from what you started from.
> 
> >From there, look at the Install.sh file after I modified it. There's
> >no 
> reason for the man page to be treated the same as every other file.
> We can write exceptions, lots and lots of them if we want to.
> 
> So what you should do is to check in the real src code and the
> script(s) you run to create the output man page. Make sense?
> 

OK, I moved the whole lot up - have a look and see what y'all think.

Steve: I tweaked the man page a little more from what you done.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] man page

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

On Sunday, Oct 5th 2008 at 12:10 -0000, quoth Nick Warne:

=>On Sun, 5 Oct 2008 10:49:34 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> On Sunday, Oct 5th 2008 at 05:56 -0000, quoth Nick Warne:
=>> 
=>> =>On Sat, 4 Oct 2008 21:53:46 -0400 (EDT)
=>> =>"Steven W. Orr" <st...@sy...> wrote:
=>> =>
=>> =>> I moved bashburn.1.gz to bashburn.1
=>> =>> 
=>> =>> I also did a bit of hacking in the manpage structure. I'm not
=>> great =>> at the macro usage but I did fix a few things. Let me know
=>> if you see =>> any problems.
=>> =>
=>> =>Steve, you should have said.  I have a man page template, and the
=>> =>bashburn man page gets created from that using sed wizardry - that
=>> way =>it is easy to change anything.
=>> =>
=>> =>http://anaturb.net/create_man_p.htm
=>> 
=>> Sorry, I don't understand. Is there a template somewhere?
=>
=>Yes, I have a bashburn template directory, so I edit the template and
=>then create the man page.
=>
=>I was wondering where it should go, as it should NOT be in the release
=>files, so I guess it could live in trunk only just for man page edits,
=>and just the man page itself gets moved over to release.
=>
=>Let me do some documentation and upload it anyway.

Now I see the problem. The content and shape of the src repository has 
nothing at all to do with the content and shape of the released code.

So.... If you have a script, or a body of software that should be executed 
in order to generate a man page, then the man page itself should not be 
checked into the repository at all. IOW, the file bashburn.1 (.gz or 
otherwise) is not a file that was *written* by a person. It's a file that 
was generated. (If you ever worked in the ClearCase world, we would call 
such things "derived objects".) You have some file which right now is 
sitting in Merry Old England and that was used as input to something which 
resulted in bashburn.1 . If you got hit by a bus then we'd be sitting on 
the .1 file, which probably isn't a huge loss (the file, not you), but 
we'd have no way to start from what you started from.

>From there, look at the Install.sh file after I modified it. There's no 
reason for the man page to be treated the same as every other file. We can 
write exceptions, lots and lots of them if we want to.

So what you should do is to check in the real src code and the script(s) 
you run to create the output man page. Make sense?

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

Re: [Bashburn-info] man page

[Nick W. <ni...@uk...>]

On Sun, 5 Oct 2008 10:49:34 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> On Sunday, Oct 5th 2008 at 05:56 -0000, quoth Nick Warne:
> 
> =>On Sat, 4 Oct 2008 21:53:46 -0400 (EDT)
> =>"Steven W. Orr" <st...@sy...> wrote:
> =>
> =>> I moved bashburn.1.gz to bashburn.1
> =>> 
> =>> I also did a bit of hacking in the manpage structure. I'm not
> great =>> at the macro usage but I did fix a few things. Let me know
> if you see =>> any problems.
> =>
> =>Steve, you should have said.  I have a man page template, and the
> =>bashburn man page gets created from that using sed wizardry - that
> way =>it is easy to change anything.
> =>
> =>http://anaturb.net/create_man_p.htm
> 
> Sorry, I don't understand. Is there a template somewhere?

Yes, I have a bashburn template directory, so I edit the template and
then create the man page.

I was wondering where it should go, as it should NOT be in the release
files, so I guess it could live in trunk only just for man page edits,
and just the man page itself gets moved over to release.

Let me do some documentation and upload it anyway.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] man page

[Nick W. <ni...@uk...>]

On Sat, 4 Oct 2008 21:53:46 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> I moved bashburn.1.gz to bashburn.1
> 
> I also did a bit of hacking in the manpage structure. I'm not great
> at the macro usage but I did fix a few things. Let me know if you see
> any problems.

Steve, you should have said.  I have a man page template, and the
bashburn man page gets created from that using sed wizardry - that way
it is easy to change anything.

http://anaturb.net/create_man_p.htm

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] man page

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

I moved bashburn.1.gz to bashburn.1

I also did a bit of hacking in the manpage structure. I'm not great at the 
macro usage but I did fix a few things. Let me know if you see any 
problems.

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

[Bashburn-info] Mailing list

[Nick W. <ni...@uk...>]

On Sat, 04 Oct 2008 22:54:31 +0200
Anders Lindén <and...@gm...> wrote:

> On Mon, 2008-09-29 at 23:06 +0100, Nick Warne wrote:
> > On Mon, 29 Sep 2008 18:32:45 +0100
> > Nick Warne <ni...@li...> wrote:
> > 
> > > On Mon, 29 Sep 2008 13:31:17 -0400 (EDT)
> > > "Steven W. Orr" <st...@sy...> wrote:
> > > 
> > > > On Monday, Sep 29th 2008 at 13:22 -0000, quoth Nick Warne:
> > > > 
> > > > =>
> > > > =>I have been messing with a man page today - I really just
> > > > gleaned the =>existing docs, but I think it looks OK.
> > > > =>
> > > > =>I have attached the file - save it, then just run 'man
> > > > <path_to_file>'. =>
> > > > =>If y'all think it's OK, I will add to repository and Install
> > > > scripts. =>
> > > > =>I looked at 'man man' and presume it belongs in man(7).  It
> > > > not, please =>correct me, and I will fix up.
> > > > 
> > > > No, it should go into section 1.
> > > > Section 1. User commands
> > > > Section 2. System calls
> > > > Section 3. Runtime library calls.
> > > > Section 4. Special files
> > > > Section 5. File formats
> > > > Section 6. Games.
> > > > Section 7. Misc
> > > > Section 8. Admin and priviledged stuff.
> > > > 
> > > > There's no requirement (any more) for bb to be installed by
> > > > root and you don't have to be root to run it. It should go in
> > > > section 1.
> > > > 
> > > > 
> > > > :-) man man gave you a description of the 'an' macro set used to
> > > > produce man pages. You do that by using the -m option to
> > > > specify the macro package you want. In this case the package is
> > > > called 'an' so that people would run groff -man for the purpose
> > > > of confusing them.
> > > > 
> > > 
> > > I have built the man page OK... is anybody getting my attachments?
> > 
> > OK, I ask this again  - does everybody get the attachment here, or
> > is it the SF mailing list being clever and strips it on return to
> > myself?
> > 
> 
> I'm not getting anything. Seems like attachements are stripped. (Or is
> that just me?)

The mailing list seems to have gone real tits-up.  Good job we got
there when we did, else trying to communicate with this mess would be
impossible.

Nick

-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Man page

[Anders L. <and...@gm...>]

On Mon, 2008-09-29 at 23:06 +0100, Nick Warne wrote:
> On Mon, 29 Sep 2008 18:32:45 +0100
> Nick Warne <ni...@li...> wrote:
> 
> > On Mon, 29 Sep 2008 13:31:17 -0400 (EDT)
> > "Steven W. Orr" <st...@sy...> wrote:
> > 
> > > On Monday, Sep 29th 2008 at 13:22 -0000, quoth Nick Warne:
> > > 
> > > =>
> > > =>I have been messing with a man page today - I really just gleaned
> > > the =>existing docs, but I think it looks OK.
> > > =>
> > > =>I have attached the file - save it, then just run 'man
> > > <path_to_file>'. =>
> > > =>If y'all think it's OK, I will add to repository and Install
> > > scripts. =>
> > > =>I looked at 'man man' and presume it belongs in man(7).  It not,
> > > please =>correct me, and I will fix up.
> > > 
> > > No, it should go into section 1.
> > > Section 1. User commands
> > > Section 2. System calls
> > > Section 3. Runtime library calls.
> > > Section 4. Special files
> > > Section 5. File formats
> > > Section 6. Games.
> > > Section 7. Misc
> > > Section 8. Admin and priviledged stuff.
> > > 
> > > There's no requirement (any more) for bb to be installed by root and
> > > you don't have to be root to run it. It should go in section 1.
> > > 
> > > 
> > > :-) man man gave you a description of the 'an' macro set used to
> > > produce man pages. You do that by using the -m option to specify the
> > > macro package you want. In this case the package is called 'an' so
> > > that people would run groff -man for the purpose of confusing them.
> > > 
> > 
> > I have built the man page OK... is anybody getting my attachments?
> 
> OK, I ask this again  - does everybody get the attachment here, or is
> it the SF mailing list being clever and strips it on return to myself?
> 

I'm not getting anything. Seems like attachements are stripped. (Or is
that just me?)

> Nick
-- 

[Bashburn-info] Is Dr Who running...

[Nick W. <ni...@uk...>]

The mailing list....

lol.

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] BashBurn (finds) and fixes other bugs...

[Nick W. <ni...@uk...>]

Something that I had an issue with during testing...

Read from bottom up:

http://marc.info/?t=122311292800002&r=1&w=2

:-D  Sorted!

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] svn problem

[Nick W. <ni...@uk...>]

On Sat, 04 Oct 2008 02:27:12 +0200
Markus Kollmar <mar...@on...> wrote:

> hi all. I have a problem i never had with bashburn/svn. after
> updating my workspace in root-dir with "svn update" i got:
> 
> U    trunk/burning/burning.sh
> U    trunk/docs/INSTALL
> U    trunk/docs/ChangeLog
> U    trunk/docs/CREDITS
> U    trunk/func/isofunc.sh
> U    trunk/func/audiofunc.sh
> U    trunk/func/datafunc.sh
> D    releases/3.0
> svn: Failed to add directory 'releases/3.0': object of the same name 
> already exists
> 
> 
> But the dir "release/3.0" was already in my workplace - don't know
> what is going on? Looking in the dir "release/3.0" with "ls":
> 
> lang/
> 
> Where are all the directories gone? Steven is it because you want
> create new dir structure?
> Or have I forgotten to read some recent mails of this mailing list
> about some changes? But then anyway i should not get this "error"?

This works OK here.  I see Anders deleted the release tree then moved
the trunk stuff across - perhaps you happened to svn update exactly the
same time and thus the release tree wasn't yet finished populating?

Try again this morning.

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] svn problem

[Markus K. <mar...@on...>]

hi all. I have a problem i never had with bashburn/svn. after updating 
my workspace in root-dir with "svn update" i got:

U    trunk/burning/burning.sh
U    trunk/docs/INSTALL
U    trunk/docs/ChangeLog
U    trunk/docs/CREDITS
U    trunk/func/isofunc.sh
U    trunk/func/audiofunc.sh
U    trunk/func/datafunc.sh
D    releases/3.0
svn: Failed to add directory 'releases/3.0': object of the same name 
already exists


But the dir "release/3.0" was already in my workplace - don't know what 
is going on? Looking in the dir "release/3.0" with "ls":

lang/

Where are all the directories gone? Steven is it because you want create 
new dir structure?
Or have I forgotten to read some recent mails of this mailing list about 
some changes? But then anyway i should not get this "error"?

---

My recent posting about the modification of "BashBurn.sh":
Yes one reason was to get simple testing in workspace. But ok it is 
right, to use the install procedure with "--prefix" is a way to do this.

To the "Install.sh":
The linux distributions could  remove this file if they create a package 
for the distribution and may manually set the BBROOTDIR.


Markus

[Bashburn-info] Problem with the man page for bb

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

I see bashburn.1.gz.

We need to not keep the .gz file in svn. That should be deleted and 
replaced with the ungzipped version. Then the Install file should be 
modified to put the .1 file into $prefix/share/man/man1/BashBurn.1.gz and 
the unistall code has to make sure to remove it.

I'll take care of it tonight.

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

Re: [Bashburn-info] All quiet on the BashBurn front

[Anders L. <and...@gm...>]

On Fri, 2008-10-03 at 14:30 -0400, Steven W. Orr wrote:
> On Friday, Oct 3rd 2008 at 12:32 -0000, quoth Nick Warne:
> 
> =>
> =>As far as I am concerned, this all works great now.  As I stated
> =>though, I don't *yet* do DVD stuff, so can't test that.
> =>
> =>I guess we can move this lot to release tree.
> =>
> =>Nick
> 
> I think this is pretty cool. Each of us bring certain strengths and it's 
> nice to see this whole thing which really is around the 10K lines actually 
> come together. The functional changes between then and now are only 
> somewhat visible (e.g., readline, some configure aspects,...). The 
> majority of the stuff that's going on is in what the user does not see 
> (e.g., all one process, *major* consolidation of code and hugely increased 
> maintainability, etc...)
> 
> I've contributed to open projects before, but never at this level of 
> involvement, and I'm starting to feel an inkling of what ESR must have 
> felt when he did fetchmail. I really didn't think I'd learn anything new 
> and that definitely was disproved. (I hope that didn't sound arrogant.) 
> Now we have a small laundry list of things for 3.1 and I see this as just 
> getting more fun.
> 
> It's just too bad we can't all get together for a non-virtual beer.
> 

I agree, it is very cool to see everyone working together. I really want
to thank everyone involved, you've done a great job and I think we
should be proud of what we have produced (And it's only getting better
from here on).

I'll look over documentation that will need to be updated and move trunk
over to release tonight. 

And Steve, never say never. The wife and I are planning on going over to
the US to see her family in a not to distant future. One day a confused
swede might be standing on your door step. :-)

-- 
Anders Lindén
http://bashburn.dose.se

Re: [Bashburn-info] All quiet on the BashBurn front

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

On Friday, Oct 3rd 2008 at 12:32 -0000, quoth Nick Warne:

=>
=>As far as I am concerned, this all works great now.  As I stated
=>though, I don't *yet* do DVD stuff, so can't test that.
=>
=>I guess we can move this lot to release tree.
=>
=>Nick

I think this is pretty cool. Each of us bring certain strengths and it's 
nice to see this whole thing which really is around the 10K lines actually 
come together. The functional changes between then and now are only 
somewhat visible (e.g., readline, some configure aspects,...). The 
majority of the stuff that's going on is in what the user does not see 
(e.g., all one process, *major* consolidation of code and hugely increased 
maintainability, etc...)

I've contributed to open projects before, but never at this level of 
involvement, and I'm starting to feel an inkling of what ESR must have 
felt when he did fetchmail. I really didn't think I'd learn anything new 
and that definitely was disproved. (I hope that didn't sound arrogant.) 
Now we have a small laundry list of things for 3.1 and I see this as just 
getting more fun.

It's just too bad we can't all get together for a non-virtual beer.

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

[Bashburn-info] All quiet on the BashBurn front

[Nick W. <ni...@uk...>]

As far as I am concerned, this all works great now.  As I stated
though, I don't *yet* do DVD stuff, so can't test that.

I guess we can move this lot to release tree.

Nick
-- 
Free Software Foundation Associate Member 5508

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

[Nick W. <ni...@uk...>]

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

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

[Anders L. <and...@gm...>]

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

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

[Nick W. <ni...@uk...>]

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

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

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

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

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

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

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

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

[Nick W. <ni...@uk...>]

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

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

[Nick W. <ni...@uk...>]

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

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

[Nick W. <ni...@li...>]

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

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

[Nick W. <ni...@uk...>]

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

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

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

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