[Libburn-hackers] Re: [Libburn-cutters] Re: Revival! And also question about burn_drive_scan with busy drives

David Mohr damailings at mcbf.net
Fri Apr 25 17:20:22 CDT 2008

Yeah, I didn't read the mailing list descriptions right, so I'm taking
this to -hackers...

On Fri, Apr 25, 2008 at 2:09 AM, Thomas Schmitt <scdbackup at gmx.net> wrote:
> Hi,
>  > When the drive is mounted, and xfburn is started, then I can't get
>  > access to the drive and burn_drive_scan returns 0 drives found. What
>  > I'm missing is a way to enumerate drives even when they are currently
>  > busy. I've looked through the API and I didn't see anything that would
>  > get me that at the moment.
>  > ...
>  > So I could get this list through i.e. HAL, but I'd rather keep my core
>  > code libburn only. Is there a way that I could get that functionality
>  > into libburn?
>  That would be API call
>   burn_preset_device_open(0, 0, 0);
>  but be warned that this might be a bad idea.
>  Normally libburn stays away from any drive that is
>  opened with O_EXCL flag. Afaik, mount does this
>  to indicate that it works on the drive.
>  libburn itself uses open(O_EXCL) to coordinate
>  with other instances of itself or with other
>  burn programs which use O_EXCL too.
>  The problem with accessing busy drives is that
>  even the slightest glimpse might spoil an
>  ongoing burn run.
>  It's like quantum mechanics: you do not know
>  before you disturbed a potentially delicate state.

Ok, so that's not what I want to do then :-)

>  > The reason is that in a GUI program I can't just bail out because the
>  > drive is currently mounted. Rather the behavior that I want to get is
>  > to list the drive, and try to automatically unmount it.
>  Seems ok for the mount case but not ok for the case
>  of concurrently running burn programs.
>  If you touch a burning drive then the burn might fail
>  immediately.
>  With the case of a mounted drive i would advise to
>  set burn_preset_device_open(0, 0, 0) only for getting
>  an overview, to afterwards give up all found drives
>  by burn_drive_info_free() and to re-enable the
>  exclusive locking by
>   burn_preset_device_open(1, 0, 0);
>  before doing a normal aquiration of drives.
>  This gives you the best chances not to collide
>  with other programs on a drive. It is still not
>  overly user-safe, i must say.

It's too bad I don't have two drives to actually see if I would screw
up my burn ;-).
As far as I understand you, the initial burn_preset_device_open(0,0,0)
could still disturb another ongoing burn, so what about the following:
If libburn would return me those devices that are currently opened
O_EXCL, then I can go and check through some means (i.e. by looking at
/etc/mtab) that the reason for the O_EXCL is a mount. If so, then I
can safely attempt to unmount it. It'd be sweet if libburn could
return me those devices though, because I don't know (or want to know
:-P ) which ones I need to check...

>  > So I could get this list through i.e. HAL,
>  Do you have experience with HAL ?
>  Do you know a way to tell HAL to stay away from
>  a particular drive for a while ?
>  For now, HAL is the biggest menace to libburn.
>  On my SuSE 10.2 i have to shoot the processes
>   hald-addon-storage
>  which guard my drives. If i let them live, then
>  they grope my drives which spoils my burns.

I haven't had that problem yet, and I have that process running on my system...

>  I would like to send HAL a message when libburn
>  grabs a drive and another message when the drive
>  gets released. Inbetween it shall not touch my
>  drive in what way ever.
>  Any hint is welcome.

Hm, have you talked to the HAL guys? Seems like this really should be
something that is necessary, if it's not currently implemented.

On a side node, if libburn opens the device with O_EXCL, how come it
is even possible to disturb the device then? Does Linux not enforce
the exclusiveness correctly?

>  Have a nice day :)
>  Thomas

Thanks for the good background info!


More information about the Libburn-hackers mailing list