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

Thomas Schmitt 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
permissions say:
  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
like GLib.

> >
> >  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 mailing list