Rob Bogus wrote:
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?
The burner software can open exclusive - see man open.
After looking
Rob Bogus wrote:
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?
The burner software can open exclusive - see man open.
After looki
>From [EMAIL PROTECTED] 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 spe
>From [EMAIL PROTECTED] 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 spe
On Sat 31 January 2004 22:46, 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?
> > >
> > > The burner softw
On Sat 31 January 2004 22:46, 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?
> > >
> > > The burner softw
> > The burner software can open exclusive - see man open.
>
> You mean O_EXCL? That doesn't seem to make sense?
You must be referring to the fact that O_EXCL is essentially undefined
without O_CREAT. It's absolutely true, but it doesn't mean that it's not
passed down to kernel, most notably when
> > >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
> > The burner software can open exclusive - see man open.
>
> You mean O_EXCL? That doesn't seem to make sense?
You must be referring to the fact that O_EXCL is essentially undefined
without O_CREAT. It's absolutely true, but it doesn't mean that it's not
passed down to kernel, most notably when
> > >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
On Sat 31 January 2004 16:30, Rob Bogus wrote:
> 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?
>
> The burner software can o
Joerg Schilling wrote:
From: Lourens Veen <[EMAIL PROTECTED]>
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 man
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?
The burner software can open exclusive - see man open.
--
E. Robert Bogusta
It seemed
Joerg Schilling wrote:
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 automo
On Sat 31 January 2004 16:30, Rob Bogus wrote:
> 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?
>
> The burner software can o
Lourens Veen wrote:
On Tue 27 January 2004 11:16, Lourens Veen wrote:
On Tue 27 January 2004 08:06, Lourens Veen wrote:
Then there is autofs
(http://freshmeat.net/projects/autofs/?topic_id=142, can't find
a real homepage) and KDE uses fam
(http://oss.sgi.com/project
Joerg Schilling wrote:
From: Lourens Veen <[EMAIL PROTECTED]>
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 man
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?
The burner software can open exclusive - see man open.
--
E. Robert Bogusta
It seem
Joerg Schilling wrote:
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 automo
Lourens Veen wrote:
On Tue 27 January 2004 11:16, Lourens Veen wrote:
On Tue 27 January 2004 08:06, Lourens Veen wrote:
Then there is autofs
(http://freshmeat.net/projects/autofs/?topic_id=142, can't find
a real homepage) and KDE uses fam
(http://oss.sgi.com/project
On Tue 27 January 2004 11:16, Lourens Veen wrote:
> On Tue 27 January 2004 08:06, Lourens Veen wrote:
> > Then there is autofs
> > (http://freshmeat.net/projects/autofs/?topic_id=142, can't find
> > a real homepage) and KDE uses fam
> > (http://oss.sgi.com/projects/fam/), however I don't think fam
On Tue 27 January 2004 11:16, Lourens Veen wrote:
> On Tue 27 January 2004 08:06, Lourens Veen wrote:
> > Then there is autofs
> > (http://freshmeat.net/projects/autofs/?topic_id=142, can't find
> > a real homepage) and KDE uses fam
> > (http://oss.sgi.com/projects/fam/), however I don't think fam
>From: Lourens Veen <[EMAIL PROTECTED]>
>> 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
>From: Lourens Veen <[EMAIL PROTECTED]>
>> 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
On Thu 29 January 2004 12:34, Joerg Schilling wrote:
> From [EMAIL PROTECTED] 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.
Thank
>From [EMAIL PROTECTED] 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.
This is why accessing the drive for writing needs to suspend the
vol
On Thu 29 January 2004 12:34, Joerg Schilling wrote:
> From [EMAIL PROTECTED] 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.
Thank
>From [EMAIL PROTECTED] 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.
This is why accessing the drive for writing needs to suspend the
vol
> It seems that the Sun volume mamager performs a dummy mount for
> empty medium and remains quiet until you call "eject cd".
Upon CD/DVD media load Solaris volume manager arranges kind of "bypass"
device entry under /vol and then invokes rmmount. Rmmount analyzes the
media to identify the file sy
> It seems that the Sun volume mamager performs a dummy mount for
> empty medium and remains quiet until you call "eject cd".
Upon CD/DVD media load Solaris volume manager arranges kind of "bypass"
device entry under /vol and then invokes rmmount. Rmmount analyzes the
media to identify the file sy
>From [EMAIL PROTECTED] 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.
On Wed 28 January 2004 16:07, Joerg Schilling wrote:
> From [EMAIL PROTECTED] 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
>
>From [EMAIL PROTECTED] 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.
On Wed 28 January 2004 16:07, Joerg Schilling wrote:
> From [EMAIL PROTECTED] 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
>
> True, but having an automounter like autofs would be an easy way of
> implementing this, and it has the advantage that it'll also work
> from outside of the DE.
Hm, true. Any distro actually using autofs though? SuSE isn't, don't
know about others. Can one assume that people who use the comman
> True, but having an automounter like autofs would be an easy way of
> implementing this, and it has the advantage that it'll also work
> from outside of the DE.
Hm, true. Any distro actually using autofs though? SuSE isn't, don't
know about others. Can one assume that people who use the comman
On Wed 28 January 2004 00:28, Volker Kuhlmann wrote:
> > 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
On Wed 28 January 2004 00:28, Volker Kuhlmann wrote:
> > 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
> 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 moth
> 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 moth
On Tue 27 January 2004 12:06, Joerg Schilling wrote:
> From: Lourens Veen <[EMAIL PROTECTED]>
>
> >"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
On Tue 27 January 2004 12:06, Joerg Schilling wrote:
> From: Lourens Veen <[EMAIL PROTECTED]>
>
> >"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
>From: Lourens Veen <[EMAIL PROTECTED]>
>"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, updatin
>From: Lourens Veen <[EMAIL PROTECTED]>
>"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, updatin
On Tue 27 January 2004 08:06, Lourens Veen wrote:
>
> Then there is autofs
> (http://freshmeat.net/projects/autofs/?topic_id=142, 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
On Tue 27 January 2004 08:06, Lourens Veen wrote:
>
> Then there is autofs
> (http://freshmeat.net/projects/autofs/?topic_id=142, 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
> 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
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 troub
> 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
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 troub
48 matches
Mail list logo
