[Libburn] Re: Handling abort situations with libburn

[scdbackup at gmx.net]

Hi,

> So, you'll run almost a complete burn time, then turn it into a coaster at 
> the last second.

Yeah. That's about what i perceive.

The late coaster aspect is not really important because
the input already died at the time when signal handling
started. Libburn is actually burning 0s from then on.


> Thomas, are you keeping a running list of all the problems you've found? 
> A repost would save me some sorting through the mess I laughingly call my 
> mailbox. :/

I keep track of the open problems.
They are mainly the old ones as listed in
http://lists.freedesktop.org/archives/libburn/2005-December/000309.html
minus speed setting problems (was me and my burner's fault)
plus burn_drive_cancel()
plus the need to emancipate from cdrecord -abort


I was not able to test the changes which you
have already done, because i would first have to
switch to your current CVS version.
For that i need the often mentioned two features:

- a burn_source constructor with fd and size 
  plus pipe-safe read function. See my patch proposal
  http://lists.freedesktop.org/archives/libburn/2005-December/000308.html

- a function as alternative to burn_drive_scan() which
  does not touch any drive than the one with the
  given address.
  It turned out that i would have painful problems with
  the proposed scanless grab call. I would really need
  a single-drive "scan" and the freedom to later grab or not.

All my other modifications would be obsolete if the
announced protection against r-but-not-w drives works.
(We still have a certain problem with ill or busy
drives in full bus scan situations. But full bus scan
is only needed for configuration situations, not for
operating a particular drive.)

Since i seem to be a major opportunity for you to get
your code tested, it would be quite economical for
your project to soon get cdrskin back on standard libburn.


Joerg Schilling recently declared libburn dead on birth.
I'd like to flounder a bit in front of his eyes.
But for that i would need a few growth hormones.
TAO with unspecified track size and some -abort capabilities
are about the last features where cdrskin is inferior
to cdrecord for data writing purposes.

There are emerging little partial advantages over cdrecord:
- less demanding system privileges
- smaller binary
- blanking is less obtrusive (i should test cdrecord -immed)

With my daily usage i win about 10 percent throughput
over cdrecord because my DVD-ROM can checkread the 
previous CD without disturbing the DVD/CD writer 
working on the next one with 8x speed.
Regrettably i lose most of the gained time with the
last CD of a backup set which gets filled up to 650 MB
regardless of its payload. (Because i cowardly announced
650 MB to be able to accept any reasonable input stream.)


Oh, before i forget:
I will probably be confronted with the statement that
allowing normal users write access to a burner at /dev/hdc
imposes a security problem.
Any idea what exactly could be that problem ?
By chance even a possible answer to that statement ?
Is it really necessary to restrict w-access to /dev/hdc
to the superuser in order to avoid system hacks ?

To write a safe setuid program is quite a challenge.
I would prefer to have cdrskin operated by normally
authenticated users who are responsible for the
inadverted consequences of their options and environment
settings.


Have a nice day :)

Thomas