Hi,
Rocky Bernstein wrote:
> > > In particular there is
> > > read/write (_AM_MMC_RDWR) and read/write exclusive (_AM_MMC_RDWR_EXCL)
I wrote:
> > Aren't those about the exclusive or shared use of the device file ?
> I am not sure I uderstand. The "device file" can be be a device like
> /dev/sr0 or /dev/cdrom with is the CD/ROM device.
For example in cdio_open_am_linux(), _AM_MMC_RDWR causes open(2) with
open_access_mode |= O_RDWR;
whereas _AM_MMC_RDWR_EXCL causes
open_access_mode |= O_RDWR | O_EXCL;
On a Linux device file, O_EXCL causes open(2) to fail if another file
descriptor opened with O_EXCL is still open. (This is not the POSIX
meaning of O_EXCL, which is undefined for device files.)
But Samuel May experiences the drive tray locked against the user.
This is a MMC feature, which may or may not be applied by the operating
system on open or by a program which sends the SCSI command to lock the
tray.
https://www.kernel.org/doc/Documentation/ioctl/cdrom.txt
lists:
CDROM_LOCKDOOR lock or unlock door
usage:
int lock;
ioctl(fd, CDROM_LOCKDOOR, lock);
inputs:
Door lock flag, 1=lock, 0=unlock
If higher levels than SCSI/MMC are used, the default behavior of the
operating system can vary.
For example on Linux 3.16 it is normal that USB attached drives have the
tray locked after reading by dd, whereas SATA attached drives can get
ejected without having to seek help from inside the computer.
This might even be Samuel May's problem: Having read data from the drive
by POSIX i/o like read(2).
(I have a little list of Linux bugs. Some diagnosed and with remedy
proposal. If ever an interested kernel developer reads this: Contact me
via scdbac...@gmx.net .)
Have a nice day :)
Thomas
