[Libburn-hackers] Re: [Libburn-cutters] Re: Revival! And also
question about burn_drive_scan with busy drives
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:
> > 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
> 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
> 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 :)
Thanks for the good background info!
More information about the Libburn-hackers