Bug 63281
Summary: | CD-R(W) access conflicts hang kernel | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Craig Lawson <craig.lawson> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | hp, notting |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-30 15:39:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Craig Lawson
2002-04-11 23:25:14 UTC
This has nothing to do with Nautilus, Nautilus isn't even involved in what happens (magicdev happens to access the CD device; but it could as easily be anything else). a) as per another bug in here somewhere, there must be a way to lock the CD device. This can be a userspace convention, it can be F_SETLK, or it can be a new system call; but the docs or feature must be in the kernel or other system-level package. If I put such docs or feature in the GNOME packages, then cdrecord etc. will NOT use it. The kernel (and some small set of other things) form our hardware abstraction layer. At that level the concurrent access problem must be solved. If I don't have a way to lock the CD device, I can't fix this bug. b) I don't think the kernel should export system calls to userspace that let you lock the kernel, anyhow (isn't this a security issue?), but I don't know enough about the issue to say that definitively. Anyway, I do not want to see this bug on any GNOME package until I have a way to lock the CD device that I can ask cdrecord to use. Feel free to pass the buck to "distribution" or something instead of kernel. ;-) But I need the locking problem solved below the desktop layer before I can do anything about it. cc'ing Bill since maybe he owns just-above-the-kernel packages that could address the locking issue. BTW, to me mandatory locking has a lot of appeal here vs. advisory, since the consequences of concurrent access are pretty dire. Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |