[Libburn] Re: Cancelling an ongoing burn. Is this dangerous ?
danakj at gmail.com
Thu Feb 9 09:27:19 PST 2006
On 2/9/06, scdbackup at gmx.net <scdbackup at gmx.net> wrote:
> > > 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
> 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
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
More information about the libburn