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

scdbackup at gmx.net scdbackup at gmx.net
Thu Feb 9 09:20:40 PST 2006


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.

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.

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.


Have a nice day :)

Thomas



More information about the libburn mailing list