[Libburn-hackers] Re: Revival! And also question about
burn_drive_scan with busy drives
scdbackup at gmx.net
Wed Apr 30 01:04:22 CDT 2008
> > E.g. as a separate GUI option "Assess Drives"
> Hmm, I want to stay away from that too :-). Not considering the
> practical problems that we are having, I want to be as automatic as
> possible, and that means no more manually scanning for devices.
How about automatic assessment of unused drives
and maintaining a list of drives which have been
found that way ?
I.e. you would do _safe_ automatic scans and
keep track with what can be found. If a drive
does not appear during a scan, you don't throw it
out of the list necessarily.
> > For a first overview of drives you might need
> > to be superuser anyway.
> Good hint, I should probably add that to our warning when no drives
> can be found. But the access problem exists for burning as well, so
> this is a general issue.
You depend on the system setup or on the sysadmin.
As said, my SuSE 10.2 allows the desktop user to
access all optical drives although the vanilla
brw-rw---- 1 root root 11, 0 Mar 7 09:44 /dev/sr0
That's due to an ACL setting, which gets not visible
with ls -l.
> > A single drive is enough. You only need two programs
> > which compete about access to it.
> Hmm, I should try that out sometimes when I feel like wasting some media ;-).
CD-RW would not be wasted.
> > But you do not know whether you unmount a removable
> > hard disk or an optical drive.
> True, although I might be able to get that info from hal which I would
> hope acquired it during the boot process.
A problem with HAL seems to be that it
has no usable plain C API but that you
have to employ some fat desktop library
> > But first you should make sure that this approach
> > really is free of severe problems due to the inability
> > to distinguish a /dev/hda hard disk from a /dev/hda
> > DVD burner. (Maybe the mount point "/media/..." can be
> > used as a criterion.)
> I don't like that heuristic :-). I'm sure some people choose to use
> different mount points. I'm not sure if I should implement the
> automatic unmount at this point, it seems like it is connected to too
> many issues. It'd be nice to have, but it's too much trouble right now
> for the payoff. Maybe later I'll go and tackle this.
Maybe you should have a look at growisofs.
In transport.hxx it inspects /proc/mounts
and then tries to unmount the given drive.
> > > > ... hald-addon-storage ...
> Maybe this is drive specific? I.e. some drives do cause an error, and
> some don't? Hopefully when we release xfburn, the libburn code will
> get more exposure, and we can get a better idea about these issues.
Not drive specific. It's the MMC specs which say
that you may not disturb a sequential write
It depends much on the implementation of HAL
as it seems.
> > Shrug.
> Yeah, this is an unfortunate situation... as I said, hopefully we'll
> get more feedback in the near future.
We shall not give up hope.
Have a nice day :)
More information about the Libburn-hackers