Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Lourens Veen
> From: Lourens Veen <lou...@rainbowdesert.net>
>
> >On Fri 23 January 2004 20:39, Thomas J Magliery PhD wrote:
> >> Joerg, I only can detect one message in single-user mode, and
> >> it's not too helpful:
> >>
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
> >> Jan 23 14:23:09 reganlinux kernel: cdrom: This disc doesn't
> >> have any tracks I recognize!
> >> Jan 23 14:23:40 reganlinux last message repeated 31 times
> >>
> >> This is from /var/log/messages. I can't find anything else
> >> that seems to be relvent anywhere else. Just in case, at the
> >> end of my email is the whole contents of /var/log/messages
> >> from my last restart...
> >
> >Well, actually it is. I dropped it into Google, and it turns out
> >that this error comes from magicdev. From what I understand,
> >magicdev is the GNOME automounter. Try setting it to not do
> >anything automatically in Nautilus, or just kill the process and
> >see if that helps.
>
> Please give us more information.
I can't I'm afraid, I don't use GNOME, and I don't use any kind of=20
automounter either. I read something in an email in a web mail=20
archive that talked about disabling automounting for a device. I=20
figure you can just right-click on it in Nautilus and change some=20
settings, but I've never used Nautilus. Debian has the following to=20
say about magicdev:
"Package: magicdev (1.1.5-1)
A GNOME daemon for automatically mounting/playing CDs
Magicdev is a daemon that runs within the GNOME environment and=20
detects when a CD is removed or inserted. Magicdev handles running=20
autorun programs on the CD, updating the File Manager, and playing=20
audio CDs."
So my above statement was inaccurate, it's not a generic=20
automounter.
> Volume management inside KDE or GNOME is completely wrong - it
> does not belong into a GUI.
Well, I haven't looked at it in-depth, but it seems to me that=20
magicdev is an independent daemon that knows about GNOME and what=20
to do when it detects a CD in a drive. It's distributed with GNOME,=20
and provides services to it, but that's it. And calling KDE or=20
GNOME a GUI is a bit of an understatement too; they're a lot more=20
powerful and complex than say, CDE.
I agree that it would be better to have this in a separate subsystem=20
though, which could be accessible through HAL=20
(http://www.ometer.com/hardware.html).
> As more and more people get such problems, it would be nice to
> have an easy to understand desription for recognising the
> procress from a ps output and what to do to get rid of at least
> the problems with the burner.
=46rom what I've found on the web, to turn off magicdev people just=20
uninstall it. Magicdev can be recognised from the above error=20
message "This disc doesn't have any tracks I recognize!".
Then there is autofs=20
(http://freshmeat.net/projects/autofs/?topic_id=3D142, can't find a=20
real homepage) and KDE uses fam (http://oss.sgi.com/projects/fam/),=20
however I don't think fam actually mounts devices by itself, it=20
just watches files. I use (parts of) KDE myself and fam is almost=20
always running; it's never given me any problems with writing CDs.
If there's anyone here actually using magicdev or autofs, more=20
information on how to see if it's running and how to configure it=20
to stay away from CD writers would be very much appreciated
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
--
To UNSUBSCRIBE, email to cdwrite...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@other.debian.org
Volker Kuhlmann
Ick - insert CD, run a program on it. Sounds like desaster to me.
Thanks for the warning.
I'm using KDE, it's never given any trouble. To mount an inserted CD or
to play it, one has to click on the drive's desktop icon.
> If there's anyone here actually using magicdev or autofs, more
> information on how to see if it's running and how to configure it
I've been using autofs for years. It's a filesystem(!) which is
permanently mounted under /misc. The filesystem is empty. In
/etc/auto.misc you configure lines like
cd -fstype=auto,ro :/dev/cdrom
When accessing the non-existing /misc/cd, autofs does a mkdir /misc/cd
and mounts the CD there. After a configurable period of inactivity, it
unmounts the CD and removes /misc/cd. It's an automounter which mounts
on access. It can mount any filesystem incl windows shares. There is
never any interference with CD burning, unless one is silly enough to
access /misc/cd during a burn. It's a system daemon, i.e. started via
init.d.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Lourens Veen
>
> Then there is autofs
> actually mounts devices by itself, it just watches files. I use
> (parts of) KDE myself and fam is almost always running; it's
> never given me any problems with writing CDs.
It turns out that there is a daemon similar to magicdev, which is=20
used with KDE: autorun (http://sourceforge.net/projects/autorun/).=20
=46rom the description:
"autorun automagically recognizes all available CDROMs in the=20
system, mounts them upon insertion of a media and executes a=20
possible autorun executable on the CD. The user can remove the=20
media; autorun will call unmount after that."
I did a quick download and looked through the source, and it seems=20
that the binary will be called autorun. I also did a search through=20
the archives and found a reference to supermount=20
(http://supermount-ng.sourceforge.net/). There is also amd, but=20
that doesn't seem to be very widely used, and certainly not=20
installed by default. If someone installed that by hand, they can=20
probably figure out how to fix it.
So we have the following table of possible automounters interfering=20
with cdrecord on Linux:
Name Type=09 Process name
magicdev daemon magicdev?
autorun=09 daemon autorun
autofs module + daemon=09 automount
supermount module N/A=09
Detecting automounters
magicdev and autorun can probably be detected by ps, supermount (or=20
at least supermount-ng) has a /proc/fs/supermount directory. If you=20
are running autofs, you likely have a file called /etc/auto.global,=20
and there is the automount process.
Preventing automounters from interfering
Ideally, an automounter would detect writing in progress and stay=20
away from the drive while the CD is being written. I don't think=20
any of the abovementioned automounters has such a feature. As an=20
alternative, automounting could be disabled for the writer. autofs=20
is configured through a map file (see the man page) and supermount=20
is configured through /etc/fstab (see the readme). I don't know=20
about autorun and magicdev. As a last resort, the daemon-based=20
automounters could be disabled completely by killing the process=20
and/or uninstalling. The in-kernel ones would have to be disabled=20
through their configuration files, by unloading the module or by=20
recompiling the kernel.
Some other bits of information
- GNOME uses magicdev
- KDE uses autorun, at least on Red Hat
- Mandrake includes supermount, but outside of Mandrake it's=20
probably rather rare
More info, especially on configuring magicdev and autorun, is still=20
very welcome!
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Joerg Schilling
>"Package: magicdev (1.1.5-1)
>A GNOME daemon for automatically mounting/playing CDs
>Magicdev is a daemon that runs within the GNOME environment and
>detects when a CD is removed or inserted. Magicdev handles running
>autorun programs on the CD, updating the File Manager, and playing
>audio CDs."
>So my above statement was inaccurate, it's not a generic
>automounter.
Well, if you do it right, then then the automounter is the wrong
place for this functionality:
- The task os an automounter is to watch where you try to step in.
If you step into some magic land, it opens a door for you.
If you go out of the magic land, the automounter will make
it disappear.
- The task of a volume management system in on contrary is to
watch the media. If someone inderts a medium, it mounts
this medium if possible.
This is independent to where you step in. It does _not_
unmount the medium if you are obviously not interested in it.
>> Volume management inside KDE or GNOME is completely wrong - it
>> does not belong into a GUI.
>Well, I haven't looked at it in-depth, but it seems to me that
>magicdev is an independent daemon that knows about GNOME and what
>to do when it detects a CD in a drive. It's distributed with GNOME,
>and provides services to it, but that's it. And calling KDE or
>GNOME a GUI is a bit of an understatement too; they're a lot more
>powerful and complex than say, CDE.
KDE seems to have a somilar program. As I don't use Linux (note that
Solaris has a more decent volume management built into the base
operating system since 1992) and Sun obviously did remove the
unwanted features from the Solaris version, I have no idea how
KDE/GNOME on Linux really work.
>I agree that it would be better to have this in a separate subsystem
>though, which could be accessible through HAL
>(http://www.ometer.com/hardware.html).
It makes no sense to have a zillion different volume management systems
on one OS. If you do, it is close to impossible for software authors
to find out how they work and how they might be influenced by
programs like cdrecord.
On Solaris, the problem for many years was that Sun did not write
a man page for vold. Now that a man page is present, it took me
3 years to find the time to add volmgt suppport. But Note: libscg
_does_ have support for the Solaris volmgt system - there is only one!
>> As more and more people get such problems, it would be nice to
>> have an easy to understand desription for recognising the
>> procress from a ps output and what to do to get rid of at least
>> the problems with the burner.
>>From what I've found on the web, to turn off magicdev people just
>uninstall it. Magicdev can be recognised from the above error
>message "This disc doesn't have any tracks I recognize!".
You name the main problem: If there are many different volmgt systems
for Linux, programs like cdrecord cannot support them. The result is that
users just remove all of them if they like to be able to continue using
the whole system :-(
>If there's anyone here actually using magicdev or autofs, more
>information on how to see if it's running and how to configure it
>to stay away from CD writers would be very much appreciated
I would be happy, to see people working on contributions...
Note that if the support is put into e.g. cdrecord.c, it cannot make it
into the official version because this would break portability.
Volmgt support belongs into the OS specific part of libscg.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Lourens Veen
> From: Lourens Veen <lou...@rainbowdesert.net>
>
> >"Package: magicdev (1.1.5-1)
> >A GNOME daemon for automatically mounting/playing CDs
> >
> >Magicdev is a daemon that runs within the GNOME environment and
> >detects when a CD is removed or inserted. Magicdev handles
> > running autorun programs on the CD, updating the File Manager,
> > and playing audio CDs."
> >
> >So my above statement was inaccurate, it's not a generic
> >automounter.
>
> Well, if you do it right, then then the automounter is the wrong
> place for this functionality:
>
> in. If you step into some magic land, it opens a door for you.
>
> =09it disappear.
>
> -=09The task of a volume management system in on contrary is to
> =09watch the media. If someone inderts a medium, it mounts
> =09this medium if possible.
>
> =09This is independent to where you step in. It does _not_
> =09unmount the medium if you are obviously not interested in it.
Aha, thanks for explaining that. This does pose a bit of a problem=20
though if you have both: say I insert a CD, then the volume manager=20
sees it and mounts it. Then I go to my magic automounter directory=20
and it tries to mount it too. Problem. Doing away with the=20
automounter means users have to mount disks by hand (which my mum=20
would probably find too complicated), while doing away with the=20
volume management means that users get no feedback after they=20
inserted a CD in the drive, which is less bad but still undesirable=20
from a user interface perspective.
So how about this. We run a normal automounter. The volume manager=20
does not actually mount disks, but just reads the volume label.=20
This volume label is then sent to the Desktop Environment with a=20
disk change event, so that the DE can do it's "You just inserted X,=20
do you want me to do Y" thing or blink the icon and change its name=20
or whatever. Then when the user actually opens the drive, the=20
automounter kicks in and it is mounted. This way, the user could=20
insert a CD, the cut-down volume manager would detect it as empty=20
and leave it be. The DE, now knowing the CD is empty, can launch=20
the CD writing application either immediately or when the user=20
clicks the drive's icon. If the cut-down volume manager and the=20
automounter can communicate (or are the same system), the=20
automounter could even refuse to mount the CD when it knows it's an=20
empty one, thus preventing unwanted accesses that interfere with=20
writing.
It seems a clean solution to me, and implementable as well. Perhaps=20
having autofs generate events via DBUS and modifying magicdev and=20
automount to listen to that instead of to the drive directly, or=20
removing them entirely, would be enough already. That doesn't mean=20
it's not a big amount of work though :-).
> >I agree that it would be better to have this in a separate
> > subsystem though, which could be accessible through HAL
> >(http://www.ometer.com/hardware.html).
>
> It makes no sense to have a zillion different volume management
> systems on one OS. If you do, it is close to impossible for
> software authors to find out how they work and how they might be
> influenced by programs like cdrecord.
Well, given the amount and size of the differences between different=20
"Linux" distributions, perhaps it's time to start thinking of them=20
as different operating systems rather than variations of the same=20
one. You could do as many other vendors of proprietary software do=20
and only support one or a few distributions explicitly. They may=20
still be broken, but at least it makes the job of tracking the=20
problems a lot more manageable. After all, Linux is just a kernel.
> >If there's anyone here actually using magicdev or autofs, more
> >information on how to see if it's running and how to configure
> > it to stay away from CD writers would be very much appreciated
>
> I would be happy, to see people working on contributions...
Me too, and I volunteer to wrap it all up into a patch to=20
README.volmgt and a blurb for the dvd+rw-tools website.
To reiterate, we still need to know how to disable KDE autorun and=20
GNOME magicdev for a single drive.
> Note that if the support is put into e.g. cdrecord.c, it cannot
> make it into the official version because this would break
> portability. Volmgt support belongs into the OS specific part of
> libscg.
I understand that, but I don't think it's up to cdrecord to fix=20
this. Automount and magicdev assume that it's always ok to access=20
the CD drive, which is wrong, because it might interfere with CD=20
burning. If the user turns them off for the writer, the problem=20
will be solved, at least for current Linux systems.
Ideally, there would be a way to tell automount and magicdev to turn=20
this off from a program. If they actually do have such a feature,=20
it may be possible to have cdrecord disable them automatically=20
before burning. I don't know enough about either magicdev,=20
automount or cdrecord to be able to comment on the feasibility of=20
this. I'll try and find out, but I've got a paper to finish first.
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Volker Kuhlmann
In this case, you simply don't need an automounter, and SuSE shows that
nicely. User wants to open hard disk? -> Click harddisk icon. User
wants to open CD? -> Click CD icon. I'm sure my mother would be able to
manage that. Neither KDE nor gnome automounters are even shipped by
SuSE. Given the amount of trouble with them, one could call it
foresight ;) I use autofs because I chose to manually enable it.
> To reiterate, we still need to know how to disable KDE autorun and
> GNOME magicdev for a single drive.
I'd say these programs are broken if they cause coasters during
burning. This is not for cdrecord/growisofs to fix. Lodge a problem
report and urgent fix request with their maintainers, and meanwhile
include a stern warning with burning software to obliterate this kind
of nuisance software from the system during burning.
> Ideally, there would be a way to tell automount and magicdev to turn
> this off from a program.
IMHO ideally these programs would be smart enough to keep their hands
off things which they otherwise break.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Lourens Veen
> > or whatever. Then when the user actually opens the drive, the
> > automounter kicks in and it is mounted.
>
> In this case, you simply don't need an automounter, and SuSE
> shows that nicely. User wants to open hard disk? -> Click
> harddisk icon. User wants to open CD? -> Click CD icon. I'm sure
> my mother would be able to manage that. Neither KDE nor gnome
> automounters are even shipped by SuSE. Given the amount of
> trouble with them, one could call it foresight ;) I use autofs
> because I chose to manually enable it.
True, but having an automounter like autofs would be an easy way of=20
implementing this, and it has the advantage that it'll also work=20
from outside of the DE.
> > To reiterate, we still need to know how to disable KDE autorun
> > and GNOME magicdev for a single drive.
>
> I'd say these programs are broken if they cause coasters during
> burning. This is not for cdrecord/growisofs to fix. Lodge a
> problem report and urgent fix request with their maintainers, and
> meanwhile include a stern warning with burning software to
> obliterate this kind of nuisance software from the system during
> burning.
Well, I'd prefer to be a bit more subtle, and explain how to disable=20
it for selected drives rather than removing it entirely. But to=20
write the doc I need to know how...
> > Ideally, there would be a way to tell automount and magicdev to
> > turn this off from a program.
>
> IMHO ideally these programs would be smart enough to keep their
> hands off things which they otherwise break.
But that means that you lose all functionality if you have a single=20
writer in the machine that is also used for reading. If you want it=20
to work for already-written CDs, and yet not interfere with=20
burning, then unless there is a non-interfering way of determining=20
the disk type and/or whether it is being written, this is=20
impossible.
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Volker Kuhlmann
Hm, true. Any distro actually using autofs though? SuSE isn't, don't
know about others. Can one assume that people who use the command line
these days ought to know what they're doing?
> But that means that you lose all functionality if you have a single
> writer in the machine that is also used for reading. If you want it
> to work for already-written CDs, and yet not interfere with
> burning, then unless there is a non-interfering way of determining
> the disk type and/or whether it is being written, this is
> impossible.
What I meant was those autothingies should keep their hands off a disk
while a burn process is happening. Dunno whether it's possible to detect
this, but isn't that the way it should be?
Sorry, can't help further.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Lourens Veen
> From lou...@rainbowdesert.net Tue Jan 27 21:08:37 2004
>
> >Aha, thanks for explaining that. This does pose a bit of a
> > volume manager sees it and mounts it. Then I go to my magic
> > automounter directory and it tries to mount it too. Problem.
> > Doing away with the automounter means users have to mount disks
> > by hand (which my mum would probably find too complicated),
> > while doing away with the volume management means that users
> > get no feedback after they inserted a CD in the drive, which is
> > less bad but still undesirable from a user interface
> > perspective.
>
> This is a reason why Apple and Sun introduced such a beast on the
> 1980s
>
> >So how about this. We run a normal automounter. The volume
> > volume label.
>
> This is enough to interrupt the CD writing process in a way that
> creates a coaster.
Is there any way at all to check whether a CD is being written=20
without disturbing the writing process?
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Joerg Schilling
>From lou...@rainbowdesert.net Tue Jan 27 21:08:37 2004
>Aha, thanks for explaining that. This does pose a bit of a problem
>though if you have both: say I insert a CD, then the volume manager
>sees it and mounts it. Then I go to my magic automounter directory
>and it tries to mount it too. Problem. Doing away with the
>automounter means users have to mount disks by hand (which my mum
>would probably find too complicated), while doing away with the
>volume management means that users get no feedback after they
>inserted a CD in the drive, which is less bad but still undesirable
>from a user interface perspective.
This is a reason why Apple and Sun introduced such a beast on the 1980s
>So how about this. We run a normal automounter. The volume manager
>does not actually mount disks, but just reads the volume label.
This is enough to interrupt the CD writing process in a way that creates
a coaster.
>and leave it be. The DE, now knowing the CD is empty, can launch
>the CD writing application either immediately or when the user
>clicks the drive's icon. If the cut-down volume manager and the
>automounter can communicate (or are the same system), the
>automounter could even refuse to mount the CD when it knows it's an
>empty one, thus preventing unwanted accesses that interfere with
>writing.
It seems that the Sun volume mamager performs a dummy mount for
empty medium and remains quiet until you call "eject cd".
Unfortunately this does not help when you like to write multi session
CDs.
>Well, given the amount and size of the differences between different
>"Linux" distributions, perhaps it's time to start thinking of them
>as different operating systems rather than variations of the same
>one. You could do as many other vendors of proprietary software do
>and only support one or a few distributions explicitly. They may
>still be broken, but at least it makes the job of tracking the
>problems a lot more manageable. After all, Linux is just a kernel.
The big problem with REdHat and SuSE is that they are trying to make
their Linux distribution more and more proprietary (differ from others).
>> >If there's anyone here actually using magicdev or autofs, more
>> >information on how to see if it's running and how to configure
>> > it to stay away from CD writers would be very much appreciated
>>
>> I would be happy, to see people working on contributions...
>Me too, and I volunteer to wrap it all up into a patch to
>README.volmgt and a blurb for the dvd+rw-tools website.
>To reiterate, we still need to know how to disable KDE autorun and
>GNOME magicdev for a single drive.
OK, please do and report your results.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Joerg Schilling
>Is there any way at all to check whether a CD is being written
>without disturbing the writing process?
NO, if you like to check for a media change you need to access the TOC.
This is why accessing the drive for writing needs to suspend the
volume management until the writing has been completed.
Lourens Veen
> From lou...@rainbowdesert.net Wed Jan 28 21:01:50 2004
>
> >Is there any way at all to check whether a CD is being written
> >without disturbing the writing process?
>
> NO, if you like to check for a media change you need to access
> the TOC.
Thanks, but that's not what I was asking. What I want to know is, if=20
I were writing a volume management system, and I wanted to make=20
sure it didn't interfere with a write in progress, is there any way=20
for it to find out if a disk is being written without disturbing a=20
write in progress?
If this is impossible, then for the volume management not to=20
interfere with cdrecord, cdrecord must tell the volume manager that=20
it is writing.
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Joerg Schilling
>From: Lourens Veen <lou...@rainbowdesert.net>
>> NO, if you like to check for a media change you need to access
>> the TOC.
>Thanks, but that's not what I was asking. What I want to know is, if
>I were writing a volume management system, and I wanted to make
>sure it didn't interfere with a write in progress, is there any way
>for it to find out if a disk is being written without disturbing a
>write in progress?
NO
>If this is impossible, then for the volume management not to
>interfere with cdrecord, cdrecord must tell the volume manager that
>it is writing.
Well, the volume management on Solaris allows to do this by opening e.g.
/vol/dev/rdsk/c1t1d0/unknown_format
The correct name is retrieved by asking the volmgt system.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Lourens Veen
> On Tue 27 January 2004 08:06, Lourens Veen wrote:
> > Then there is autofs
> > (http://freshmeat.net/projects/autofs/?topic_id=3D142, can't find
> > a real homepage) and KDE uses fam
> > (http://oss.sgi.com/projects/fam/), however I don't think fam
> > actually mounts devices by itself, it just watches files. I use
> > (parts of) KDE myself and fam is almost always running; it's
> > never given me any problems with writing CDs.
>
> It turns out that there is a daemon similar to magicdev, which is
> (http://sourceforge.net/projects/autorun/). From the description:
I just found out that both magicdev and autorun originated at Red=20
Hat. It seems somebody decided they needed automounting=20
functionality, even if it meant a security weakness, and they=20
implemented it for both GNOME and KDE, as magicdev and autorun=20
respectively. It seems like these are separate packages, so I think=20
the best thing to do is to recommend uninstalling them wholesale.
I'll try and get a patch to README.volmgt together this weekend.
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Lourens Veen
> Volker Kuhlmann wrote:
> >What I meant was those autothingies should keep their hands off
> > a disk while a burn process is happening. Dunno whether it's
> > possible to detect this, but isn't that the way it should be?
>
You mean O_EXCL? That doesn't seem to make sense?
Volker Kuhlmann
> > > a disk while a burn process is happening. Dunno whether it's
> > > possible to detect this, but isn't that the way it should be?
> >
> > The burner software can open exclusive - see man open.
Yes, even better if the burning software can get access to the device in
such a way that accesses from other processes result in "in use - go
away".
> You mean O_EXCL? That doesn't seem to make sense?
O_EXCL When used with O_CREAT, if the file already exists
it is an error and the open will fail.
My man page doesn't mention anything about E_EXCL when used without
O_CREAT, but if the behaviour is return success only when the device
isn't in use (r or w elsewhere) and to prevent subsequent processes
from opening even read-only, then that looks like the solution. Does
the fact that growisofs/cdrecord don't seem to obtain exclusive access
to the device mean doing exactly that isn't actually possible, or
prevented otherwise?
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Lourens Veen
> > > >What I meant was those autothingies should keep their hands
> > > > off a disk while a burn process is happening. Dunno whether
> > > > it's possible to detect this, but isn't that the way it
> > > > should be?
> > >
> > > The burner software can open exclusive - see man open.
>
> Yes, even better if the burning software can get access to the
> device in such a way that accesses from other processes result in
> "in use - go away".
>
> > You mean O_EXCL? That doesn't seem to make sense?
>
> O_EXCL When used with O_CREAT, if the file already exists
> it is an error and the open will fail.
>
> My man page doesn't mention anything about E_EXCL when used
> without O_CREAT, but if the behaviour is return success only when
> the device isn't in use (r or w elsewhere) and to prevent
> subsequent processes from opening even read-only, then that looks
As far as I can tell, it says that it won't create or open the file=20
if it already exists. I'm just going by the manpage, but it doesn't=20
say anything about just opening without O_CREAT (and I reckon the=20
device file would exist), let alone that this would prevent other=20
programs from opering. If it would work without O_CREAT _and_ these=20
automounter opened with O_EXCL, then it might be the solution. But=20
I don't see that written down anywhere...
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Joerg Schilling
>From ro...@tmr.com Sat Jan 31 16:27:44 2004
>The GUI is a user interface and should do for the user what the user
>wishes done. Having the volume management (and that term means something
>else in most contexts) in the GUI allows the user to control how the
>system will behave when a specific users is on the console. Anything
>system-wide would not be doing what the individual users find useful.
>NOTE: I'm not saying that's wrong, just that there are good reasons for
>having this particular feature in the GUI and as a per-user option. I do
>believe it should be disables for any user not at the console.
There _may_ be a GUI _to_ the NON-GUI volume management, but the
volume management itself does not belong into the GUI.
>--------------010302030009000204040203
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
><html>
><head>
START TO LEARN HOW TO MAIL!
confugure your mailer so there is NO HTML
Keinen HTML Muell bitte!
No HTML junk please!
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily