From: Bodo Eggert <7eggert@elstempel.de>
To: Arjan van de Ven <arjan@infradead.org>,
Lennart Sorensen <lsorense@csclub.uwaterloo.ca>,
Dirk <noisyb@gmx.net>,
linux-kernel@vger.kernel.org
Subject: Re: PATCH/FIX for drivers/cdrom/cdrom.c
Date: Thu, 17 Aug 2006 14:27:34 +0200 [thread overview]
Message-ID: <E1GDgyZ-0000jV-MV@be1.lrz> (raw)
In-Reply-To: 6KyCQ-1w7-25@gated-at.bofh.it
Arjan van de Ven <arjan@infradead.org> wrote:
> On Wed, 2006-08-16 at 14:37 -0400, Lennart Sorensen wrote:
>> Perhaps the real problem is that some @#$@#$ user space task is
>> constantly trying to mount the disc while something else is trying to
>> write to it.
>>
>> gnome and kde both seem very eager to implement such things. perhaps
>> there should be a way to prevent any access by such processes while
>> writing to the disc.
>
> there is. O_EXCL works for this.
> Any sane desktop app and cd burning app use O_EXCL already for this
> purpose...
This was discussed to death:
HAL using O_EXCL will randomly prevent burning/mounting/etc by causing a
race condition, so it can't do that. HAL not using O_EXCL will OTOH succeed
in opening despite of O_EXCL used by the burning process and thereby
prevent burning by opening a busy device. The proposed solution was
introducing O_NONE or O_HARMLESS to prevent side-effects from opening
the device.
This will, however, not prevent other users from maliciously destroying the
CD by not using O_EXCL. Chowning the device is not a real solution, since
users should be able to fusermount the CD.
Maybe it's possible to cache the result and thereby prevent repeated
opening from disturbing the burning process.
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
http://david.woodhou.se/why-not-spf.html
next parent reply other threads:[~2006-08-17 12:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6Kxns-7AV-13@gated-at.bofh.it>
[not found] ` <6Kytd-1g2-31@gated-at.bofh.it>
[not found] ` <6KyCQ-1w7-25@gated-at.bofh.it>
2006-08-17 12:27 ` Bodo Eggert [this message]
2006-08-17 12:35 ` PATCH/FIX for drivers/cdrom/cdrom.c Arjan van de Ven
2006-08-18 12:31 ` Bodo Eggert
2006-08-18 12:53 ` Arjan van de Ven
2006-08-18 16:45 ` Alan Cox
2006-08-17 13:39 ` Alan Cox
2006-08-17 13:23 ` Lennart Sorensen
2006-08-17 13:41 ` Jeff Garzik
2006-08-17 13:54 ` Lennart Sorensen
2006-08-17 14:38 ` Helge Hafting
2006-08-18 12:39 ` Bodo Eggert
2006-08-17 13:48 ` Alan Cox
2006-08-17 14:36 ` Lennart Sorensen
2006-08-17 14:38 ` Arjan van de Ven
2006-08-17 15:09 ` Alan Cox
2006-08-19 17:52 ` Oleg Verych
2006-08-21 17:31 ` Lennart Sorensen
2006-08-16 17:26 Dirk
2006-08-16 17:40 ` Jan Engelhardt
2006-08-16 18:37 ` Dirk
2006-08-16 18:37 ` Lennart Sorensen
2006-08-16 18:44 ` Arjan van de Ven
2006-08-16 19:30 ` Dirk
2006-08-16 19:08 ` Alan Cox
2006-08-16 22:25 ` Andrew Morton
2006-08-17 7:50 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1GDgyZ-0000jV-MV@be1.lrz \
--to=7eggert@elstempel.de \
--cc=7eggert@gmx.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=noisyb@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox