[Libburn] libisofs issues

[Bryan Forbes]

Here is the problem:

libisofs works when you write the iso to the hard drive (ok, not really
a problem)
libisofs does not work when you create the iso on the fly and write it
to CD on the fly

libburn writes libisofs and mkisofs isos from the hard drive just fine.

as you can see from this chunk of code, I never write the iso I create
to the hard drive, I write it directly to CD using libburn (from the
original test case I sent in):

vs = iso_volumeset_new(1, "Test", volume_names, "Bryan Forbes", NULL,
NULL, NULL);
  iso_volumeset_set_iso_level(vs, 1);
  iso_volumeset_set_rr(vs, 1);
  iso_volumeset_set_joliet(vs, 1);

  parent = iso_volumeset_get_root(vs);
  iso_tree_add_file(parent, "/home/bryan/Projects/tests/test-
libburn/test1.txt", 1, NULL);
  iso_tree_add_file(parent, "/home/bryan/Projects/tests/test-
libburn/test2.txt", 1, NULL);
  iso_tree_add_file(parent, "/home/bryan/Projects/tests/test-
libburn/test3.txt", 1, NULL);
  iso_tree_print(parent);

  burn_iso(drives[drive].drive, vs);

This is the problem I am experiencing.  I don't want to write iso's to
the hard drive unless the user specifies they want to export to iso
because I think it's a waste of space.  I hope this clarifies my
problem.


On Sun, 2004-09-26 at 20:58 -0500, Derek Foreman wrote:
> I'm confused as to what does and does not work.
> 
> libisofs is creating a broken iso image, but libburn is capable of 
> burning an mkisofs created iso image to make a functional cd?
> 
> If that's the case, it would be quite useful to use libisofs to create an 
> iso on an x86 machine, and another on a PPC (exact same files, in same 
> order, with same options, etc etc), and compare the two.
> 
> On Sat, 25 Sep 2004, Bryan Forbes wrote:
> 
> > No, it doesn't work.
> >
> > On Sat, 2004-09-25 at 00:17 -0500, Derek Foreman wrote:
> >> On Tue, 21 Sep 2004, Bryan Forbes wrote:
> >>
> >>> Alright, burning an iso from disk works on PPC.  Creating the iso's on
> >>> the fly is another problem.  Attached is a test program adapted from
> >>> burniso.c in the test directory.  I have also attached the test text
> >>> files I use with this test file (you'll have to change the paths to the
> >>> files in the source).  Here is the output of the program running for me:
> >>>
> >>> bryan at mxpxppc:~/Projects/tests/test-libburn$ ./isoburn-c
> >>> Initializing library...Success
> >>> Scanning for devices...Done
> >>> /
> >>>  TEST1.TXT;1
> >>>  TEST2.TXT;1
> >>>  TEST3.TXT;1
> >>> ignored nwa: 0
> >>>
> >>> ctladr|trno|indx|form|scms|  msf
> >>> ------+----+----+----+----+--------
> >>> 4  1 | 00 | 00 | 01 | 00 |00:00:00
> >>> 4  1 | 01 | 00 | 10 | 00 |00:00:00
> >>> 4  1 | 01 | 01 | 10 | 00 |00:02:00
> >>> 4  1 | AA | 01 | 01 | 00 |00:02:1D
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>> S: 0/1 T: 0/1 L: -26: 5/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: -26: 29/29
> >>> S: 0/1 T: 0/1 L: 0: 0/0
> >>>
> >>> As you can see, it writes the 0's that should be put at the end of the
> >>> disc at the front of the disc.  Does this happen on x86?  Thanks in
> >>> advance!
> >>
> >> Nah the first pile of 0s are when it's writing the lead in.
> >>
> >> Does the disc work?
> > -- 
> > ======================================================================
> > Bryan Forbes
> > bryan at reigndropsfall.net
> > http://www.reigndropsfall.net
> >
> > "It does not take a majority to prevail, but rather an irate, tireless
> > minority keen to set brush fires in people's minds."
> >        - Samuel Adams, an architect of the Constitution
> >
> > Key fingerprint = 3D7D B728 713A BB7B B8B1  5B61 3888 17E0 70CA 0F3D
> >
-- 
======================================================================
Bryan Forbes
bryan at reigndropsfall.net
http://www.reigndropsfall.net

"It does not take a majority to prevail, but rather an irate, tireless
minority keen to set brush fires in people's minds."
        - Samuel Adams, an architect of the Constitution

Key fingerprint = 3D7D B728 713A BB7B B8B1  5B61 3888 17E0 70CA 0F3D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://freedesktop.org/pipermail/libburn/attachments/20040927/754931b9/attachment.pgp