Bill Davidsen wrote:
> > If you like a real solution, we would need to find a way to make the people
> > who
> > write hald from linux to become interested in fixing their bugs.
> >
>
> I don't regard it as a bug that a program does what the configuration
> file or command line options requ
Joerg Schilling wrote:
Bill Davidsen wrote:
The best solution for that problem is to kill hald ;-)
kill -STOP ` pgrep hald `
Noted. Since the only mode which seems to have a hope of working is TAO
from what people have said, raw96r seems to be a side track. And I would
certain
Bill Davidsen wrote:
> > The best solution for that problem is to kill hald ;-)
> >
> > kill -STOP ` pgrep hald `
> >
>
> Noted. Since the only mode which seems to have a hope of working is TAO
> from what people have said, raw96r seems to be a side track. And I would
> certainly edit the c
Joerg Schilling wrote:
Bill Davidsen wrote:
- Use cdrecord (or one of the plug-compatible substitutes) in TAO
burning mode.
Rather than one of the "raw" modes? I found several posts suggesting
that the magic was 'raw96r' or similar. I believe I tried that, as well
as -sao, -ta
Bill Davidsen wrote:
> > - Use cdrecord (or one of the plug-compatible substitutes) in TAO
> >burning mode.
> >
> Rather than one of the "raw" modes? I found several posts suggesting
> that the magic was 'raw96r' or similar. I believe I tried that, as well
> as -sao, -tao, and -dao, but I
"Thomas Schmitt" wrote:
> Hi,
>
> Dave Platt wrote:
> > Unfortunately, determining the end-of-data (end-of-track) location on a
> > data CD is one of those things which is difficult-to-impossible to do
> > reliably.
>
> This is actually a matter of the device driver
> and not so much of drive and
Hi,
Dave Platt wrote:
> > > Unfortunately, determining the end-of-data (end-of-track) location on a
> > > data CD is one of those things which is difficult-to-impossible to do
> > > reliably.
I wrote:
> > This is actually a matter of the device driver
> > and not so much of drive and media.
Rob
Thomas Schmitt wrote:
Hi,
Dave Platt wrote:
Unfortunately, determining the end-of-data (end-of-track) location on a
data CD is one of those things which is difficult-to-impossible to do
reliably.
This is actually a matter of the device driver
and not so much of drive and media. The si
Dave Platt wrote:
Bill Davidsen wrote:
This is not ISO9660 data. I want the burner program to take my bits
and put them on the media, nothing else. The data is in 64k chunks,
so all writes are sector complete. I haven't had any issues with
reading the data off DVD, or off CD in the case where
"Thomas Schmitt" wrote:
> Hi,
>
> Paul Serice wrote:
> > > Software put the root file system at the end of
> > > the media. For a DVD, the end of media is greater than 4GB which
> > > could not be seen because linux was using a 32-bit, byte-oriented
> > > inode scheme.
>
> Joerg Schilling wrote:
Hi,
Paul Serice wrote:
> > Software put the root file system at the end of
> > the media. For a DVD, the end of media is greater than 4GB which
> > could not be seen because linux was using a 32-bit, byte-oriented
> > inode scheme.
Joerg Schilling wrote:
> This is wrong
Multi-session software pu
Paul Serice wrote:
> The obvious thing to try is to put the root directory (more or less)
> immediately after the PVD. With read-only media, this can be a
> problem because there is no way to go back and fill in missing
> information -- like the size of files.
>
> So when the size of stdin is no
Hi,
Dave Platt wrote:
> Unfortunately, determining the end-of-data (end-of-track) location on a
> data CD is one of those things which is difficult-to-impossible to do
> reliably.
This is actually a matter of the device driver
and not so much of drive and media. The size of
a logical track as obt
Bill Davidsen wrote:
This is not ISO9660 data. I want the burner program to take my bits and
put them on the media, nothing else. The data is in 64k chunks, so all
writes are sector complete. I haven't had any issues with reading the
data off DVD, or off CD in the case where I write it to some
Paul Serice wrote:
I don't obviously see why CD burning requires the size in advance,
but cdrecord and similar seem to want it.
The meta-data for the iso9660 is in the "primary volume descriptor"
(PVD) which is (more or less) written first. One of its fields is the
location of the root di
Hi,
Bill Davidsen wrote:
> > Is there a way to burn data from a program to a CD without knowing in
> > advance how much data will be written?
Dave Platt wrote:
> (a) use track-at-once burning mode,
This is indeed the solution for CD media.
(Normally it should suffice not to use
option -sao.)
> I don't obviously see why CD burning requires the size in advance,
> but cdrecord and similar seem to want it.
The meta-data for the iso9660 is in the "primary volume descriptor"
(PVD) which is (more or less) written first. One of its fields is the
location of the root directory which varies fr
Is there a way to burn data from a program to a CD without knowing in
advance how much data will be written? I have solutions for DVD, don't
have a good one for CD. I don't obviously see why CD burning requires
the size in advance, but cdrecord and similar seem to want it.
You need to know t
Is there a way to burn data from a program to a CD without knowing in
advance how much data will be written? I have solutions for DVD, don't
have a good one for CD. I don't obviously see why CD burning requires
the size in advance, but cdrecord and similar seem to want it.
What would be useful
19 matches
Mail list logo
