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

[Derek Foreman]

By the way, apparently my ip address is listed as dynamic in "SORBS", so I 
can't send email to gmx.net directly.

Sometimes I think anti-spam solutions are worse than the cure.  Oh well.

On Sun, 11 Dec 2005, scdbackup at gmx.net wrote:

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

OK.

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

I hadn't thought of the hideous possibility of sending a .tgz or something 
as mode-1 data.

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

The last several sectors of a data track need to have the p-subchannel 
set, I think.  I can imagine the drive having a hard time guessing when to 
turn that on, when track length isn't known in advance.  Writing a few 
dummy sectors of 0s after the track should avoid that problem, I guess.

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

Your point is noted.  At a brief glance, there shouldn't be any serious 
difficulty in doing this.

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

Sorry to be dense, but can you explain to me why this is useful?

The last thing in the world I want is a bunch of wacky ifdefs so that one 
app will run against 12 different versions of the library, and runtime 
checks would be even more gruesome...

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

It has not been done.  It's close enough to the stuff in file.c that it's 
likely a very simple thing to add.  (It'll need a fake file length if it's 
to be used with non TAO modes, though)

Is there now interest? :)

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

Yup.  File permissions and ide-scsi vs not ide-scsi really muddy the 
waters for cd burning.