Are you sure that only certain people are affected, or is it possible that only certain people are aware that they are affected?
You could be correct, especially after reading GazL's post.
It affects me to, though I tend to just push the button on the front rather than type eject.
I use the physical button too, but I noticed the problem because my main office system case is several feet from my chair. Long ago I created a desktop shortcut to toggle the tray with eject -T. Yes, I still have to leave my chair to retrieve the disk, but the techie in me liked the idea of the eject shortcut. Moreso, programmatic ejection is important to me because I have an HTPC.
The eject -T command stopped working with Slackware 14.0 --- and remains broken. Slackware 14.0 was the first release without HAL, replaced by udisks(2).
My first experience
with the broken eject command came soon after 14.0 was released.
I did not immediately update my systems to 14.0, doing so several months after the release. After I moved all of my systems to 14.0, I again noticed peculiarities with the eject command. I posted a query
to find a way to determine the state of the tray. Pat responded with a short C snippet, after which you then responded to improve the crappy timeout method used in the original eject code.
The eject command breakage occurred with the transition away from HAL to udisks(2). I don't think the eject command sources are maintained anymore and like so much in free/libre software, most people no longer care.
As not all Slackers are using 14.0, that too probably contributes to people not noticing the breakage because previous releases have HAL, under which eject works.
That command does not always work.
One example is the command is not a toggle like the original eject -T command. When there is no disk in an optical drive the udisks command fails with the following:
Eject failed: No media in drive
The command also does not work when the tray is open. Same error message. The udisks command is not a replacement for eject -T.
This thread prompted to investigate again because I use the Trinity desktop. Controlling removable devices in a HAL-less system required a new hardware detection method in Trinity, of which I am helping to test.
As a result of that testing, I probably am a tad more familiar with the eject breakage. I have tried several ways to dependably eject an optical disk or toggle the tray. The bottom line is the eject command is broken.
To replace the broken eject -T command, I now use a script wrapper around the basic C detection snippet Pat created. That wrapper script and C snippet work well, regardless of eject or udisks. Yet through my recent testing for Trinity I again stumbled across the fact that eject is broken in a HAL-less system. Without the patch the eject -T command now works only one way and no longer toggles. With the patch the eject -T command works both ways.
The only dependable method I found to fix the broken eject command is to suid /usr/bin/eject. Then the eject command works much better. Yet that is not the default installation permissions and along with my testing for Trinity and the above referenced thread, I again investigated.
The patch I found needed to be modified ever-so-slightly because of the patch you created to fix the eject command's tray detection status.
The patch linked in this thread works.
I don't know the appropriate strategy for handling the unlocking mechanism. I see the point in a multi-user system, but I am not concerned much about that in the broader scope because most Linux based systems these days, even with multiple users logged on to them, more than likely don't have such issues. That is, whoever is using the optical disk tray is the only person likely to want to eject the disk and not other users concurrently logged in. I understand the problem in a mainframe-like environment, but then again, optical drives are unlikely to be remotely used and controlled. I suppose somebody could SSH into a box, unlock a drive being used, and irritate the user, but discussing these corner cases seems academic.
In the end, the patch helps fix the eject command.
* The eject command is funky in a HAL-less system.
* The udisks eject method works only when a disk is in the tray and is not a toggle.
* Setting /usr/bin/eject suid is an uncomfortable work-around.
* The patch in this thread helps avoid that work-around.
* My testing was not based upon any rigid scientific protocols.
* I'm no expert on any of this.