[Libburn] Re: Cancelling an ongoing burn. Is this dangerous ?

[Dana Jansens]

On 2/9/06, scdbackup at gmx.net <scdbackup at gmx.net> wrote:
> Hi,
>
> > > Plus the prototype of the single drive "scan" function, like
> > >
> > >   int burn_drive_scan_single(struct burn_drive_info **drive,
> > >                              char *deviceadr);
> > >
> >
> > It was a goal for libburn to use the freedesktop device demon for
> > choosing a drive eventually (with legacy support though, I think as it
> > is now), and so we avoided using any /dev paths in the API.
>
> But i thought   burn_drive_info.location  was a part of the API.
> After all i understand burn_drive_info as a kind of publisher
> for some selected drive details.

The location is there for informative purposes, but not for selecting
the drive. Or that was the original motivation.

> Currently my tool can produce a list of devices read from .location
> after a normal burn_drive_scan().
> Vice versa it is able to address drives via their .location
> by searching in the drives[] list.
> This seemed to be a very consistent and upward compatible approach
> to me.
>
> (I added a cdrecord compatibility address layer but this is
>  just a 1:1 encoding of /dev/sgN, /dev/hdX , or drivenoN .)
> (Then i added an address translation layer for programs like
>  K3b which inspect the system on their own and calculate a
>  cdrecord address on their own.)
>
>
> > On this basis I would be against adding this function as is.
>
> The motivation is as follows:
>
> I want to build a tool that is able to substitute for cdrecord.
> At least for data (i.e. backup) purposes i have achieved a
> quite sufficent result. It would be pity to give this up.
>
> To be able to fulfill the normal cdrecord use cases, the tool has
> to be able to work with a drive regardless what ill state other
> drives may have. burn_drive_scan() as it is fails if it encounters
> a drive that is busy or a drive that is ill. Notabene a drive that
> is not addressed by my tool at all. It is just present and it spoils
> everything.
>
> I generally have to object the intention not to have global and
> sufficiently stable drive addresses. How shall i configure any
> automated and reliable backup if the new sysadmin apprentice can
> change my writer drive number by changing the access rights to a
> totally unrelated CD-ROM drive ?
>
>
> It is not necessary to use "/dev/..." but i need to have a kind of
> persistent drive address. It should only be allowed to change in
> situations where a /dev/sgN or /dev/hdX is expected to change or
> where the sysadmin is clearly aware that the backup burner is
> affected.

I guess I need to find out if HAL can provide this for you, and if it
is still/yet worth linking libburn to and using.

> Additionally i need to show the sysadmin the addresses of available
> drives which might have to be configured by chmod.
> To use the same address for system management and for normal drive
> operation seems to be straightforward.
>
>
> I failed to locate a "freedesktop device demon" by help of Google.
> Can you point me to some background info ?
> I would like to look for some alternative persistent address
> or individual drive id.

Yeah... I forgot it's name. I was refering to
http://freedesktop.org/wiki/Software_2fhal

Dana