[Libburn] Re: How to pipe stdin to CD-RW ?

[scdbackup at gmx.net]

Hi,

> Derek Foreman wrote :
> I'm wondering if it's possible to determine the size of the output in an 
> initial pass that doesn't create an image file.  It'd really only have to 
> stat all the files involved, and that information should probably stay 
> around in cache long enough that the second pass won't duplicate the 
> effort.

If you ask me as a producer of on-the-fly media images
then the answer is clear.

No. This is not possible. 

The MD5 of two repeated runs of afio, star, mkisofs, or
whatever differ. There is always some file content or archive
timestamp changing. As soon as compression is allowed, any
content change is able to cause a change in size.

cdrecord got option -isosize which reads (and probably buffers)
the head of the stream and tries to interpret it as ISO-9660.
Thus it is able to determine the size early from the stream
content. But only with ISO-9660.
Any archive format that is generated by a single pass over the
file system tree will not be able to predict its size early.

cdrecord option -tao allows to burn without predicted size
on all drives which are known to me. I never got reports
that cdrecord went on strike because of that. (The man page
warns of drive dependent problems, though.)


> (I'm not saying I'm not going to write TAO, but I'd really like a 
> consistent interface amongst the three)

If you implement TAO then please try to achieve this very
convenient ability to burn without predicted size.

I believe that libburn's usability would benefit much.
Especially if alternative source readers emerge, this
would lift a lot on restrictions about potential data
sources.


---------------------------------------------------------
Is there any means to determine at compile time the
version of the libburn header and at run time a comparable
version string ?

If not : i propose macros like

#define BURN_LIBRARY_VERSION "0.2"
#define BURN_SNAPSHOT_DATE "2005.12.08.203854"

and a function
  void burn_version_strings(char library_version[80],
                            char snapshot_date[80])

It is helpful if the snapshot dates' chronological sequence 
matches the snapshot_date strings' alphabetical sequence.

The macros would help to adapt to changes in libburn.h
if one links directly the .o files.
The macros together with function would allow to check
compatibility at startup and to issue version messages.


---------------------------------------------------------
I sifted through the mailing list archives and found the
following messages interfering with my cdrskin efforts:

http://lists.freedesktop.org/archives/libburn/2004-November/000232.html
> Derek Foreman wrote :
> Alternatively, it would be pretty easy to write a libburn source function 
> for reading from a file descriptor, and you could use mkisofs and pipes.
> I'll write that if there's interest.

Was there interest ?
Did you write something already ? (Did i miss it ?)


http://lists.freedesktop.org/archives/libburn/2005-January/000245.html
>> sjs02 at mails.tsinghua.edu.cn wrote :
>>  2)When I ran the demo program burniso, function burn_drive_grab()
>>  can not return value,so program stop here in a death loop,why?
>> I can burn cd with cdrecord.
>>
> Derek Foreman wrote :
> What kernel are you using?  are you using ide-scsi or not?
>
> This could be a file permissions problem, is cdrecord setuid root? 
> does burniso work when you're root?

Looks much like the r- but not w- problem which i encountered.

---------------------------------------------------------


Have a nice day :)

Thomas