There is one really, really cool feature MS Windows has which I've never seen implemented on any Linux distro: You press the CD Eject button and the CD ejects (always!)
I know it's not the unix way, but is there any reason why this can't be done? .. given that USB stick drives can be yanked out without the machine exploding, why not CD/DVDs?
In recent years the only reasons why my Linux computer gets rebooted is: 1. Upgrade 2. Power failure 3. CD/DVD refuses to eject and someone needs it in a hurry :-)
Joe.
Joe, seems that supermount patch for linux kernel was designed for this purpose and was implemented in Mandrake linux distros
Joe Desbonnet wrote:
There is one really, really cool feature MS Windows has which I've never seen implemented on any Linux distro: You press the CD Eject button and the CD ejects (always!)
I know it's not the unix way, but is there any reason why this can't be done? .. given that USB stick drives can be yanked out without the machine exploding, why not CD/DVDs?
In recent years the only reasons why my Linux computer gets rebooted is:
- Upgrade
- Power failure
- CD/DVD refuses to eject and someone needs it in a hurry :-)
Joe.
Yuri Prushinsky wrote:
Joe, seems that supermount patch for linux kernel was designed for this purpose and was implemented in Mandrake linux distros
You are talking about supermount or supermount-ng which isnt getting upstreamed. The better way might using non hackish stuff like HAL and dbus.
Joe Desbonnet wrote:
There is one really, really cool feature MS Windows has which I've never seen implemented on any Linux distro: You press the CD Eject button and the CD ejects (always!)
I know it's not the unix way, but is there any reason why this can't be done? .. given that USB stick drives can be yanked out without the machine exploding, why not CD/DVDs?
In recent years the only reasons why my Linux computer gets rebooted is:
- Upgrade
- Power failure
- CD/DVD refuses to eject and someone needs it in a hurry :-)
Joe.
Actually, IIRC, windows (or the drive itself) locks the drive door too under operation, but the lock is released, as soon as it's not in use...
Anyways, there are plenty automounting variants available that allows this to work in one way or the other...
Hope this helps...
/Thomas
On Thu, 05 Jan 2006 15:57:53 +0100, Thomas M Steenholdt tmus@tmus.dk wrote:
Actually, IIRC, windows (or the drive itself) locks the drive door too under operation, but the lock is released, as soon as it's not in use...
That's right, and we do the same. Unfortunately for this case, a mount operation performs an open of the block device, so it's considered "in use" and that locks the door. The device driver does not know if an application had any files open within the filesystem...
It may be possible to implement something like an unlock after a period of inactivity. But all implications have to be well thought out. For now just use "eject". It unmounts, too, so it's safer anyway.
-- Pete
On Thu, 2006-01-05 at 14:04 +0000, Joe Desbonnet wrote:
I know it's not the unix way, but is there any reason why this can't be done?
There is no Unix way only the way which is best for the user.
.. given that USB stick drives can be yanked out without the machine exploding, why not CD/DVDs?
First, never yank a mounted USB device. You can't do this on any OS without possibly causing serious data loss. Because flash drives are really slow and constantly writing to them can wear them out faster, data is queued up and synced to device at regular intervals. Yanking it before a write can finish will damage the drive.
As for drives opening I would guess we could listen for the button press and do an unmount/eject. The question is do we get eject button signals from the kernel.
Hi
First, never yank a mounted USB device. You can't do this on any OS without possibly causing serious data loss. Because flash drives are really slow and constantly writing to them can wear them out faster, data is queued up and synced to device at regular intervals. Yanking it before a write can finish will damage the drive.
Right which is why Windows has a system tray message that says says remove devices or something similar. Might consider adopting a similar strategy of informing the user using libnotify and friends.
As for drives opening I would guess we could listen for the button press and do an unmount/eject. The question is do we get eject button signals from the kernel.
This has been a often requested feature which has been dumbed down so far as not being the Unix way as if that really mattered on that desktop.
On Thu, 2006-01-05 at 14:18 -0500, John (J5) Palmieri wrote:
As for drives opening I would guess we could listen for the button press and do an unmount/eject. The question is do we get eject button signals from the kernel.
Kay's already done this in HAL (for supported drives):
http://lists.freedesktop.org/archives/hal/2005-October/003679.html
I guess it has to be hooked up to g-v-m or something.
Richard.
Hi
First, never yank a mounted USB device.
Something that has been bothering me for a while, what is responsible for detecting and mounting USB devices on Fedora?
The reason I ask is that I'd like to make sure that what I consider reasonable mount options are used, including noatime and shortname=win95 (I have a FAT based mp3 player that by default mounts but is unusable due to the default shortname setting)
I would like to reconfigure it and if code changes are necessary to allow configurability then I might still be tempted. So please point me in the direction of something relevant...
-Cam
From: Cam camilo@mesias.co.uk References: 1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com 1136488717.22333.42.camel@remedyz.boston.redhat.com
First, never yank a mounted USB device.
[...]
Cam didn't quote relevant headers, so I cannot be sure with whom I am disagreeing here, and I do not see the original message in the thread. Remedyz.boston is J5's box.
Anyway, it's completely safe to yank a mounted USB device, as far as system is concerned. If someone disagrees, we'll meet at dawn. :-) Your data on it may suffer, but hey, that's called "freedom" (to hurt yourself).
Current VFS orphans necessary files and inodes just fine in case of a forced umount. Even if there was no umount, ub correctly orphans the block device (actually, I think usb-storage and sd_mod try too). So you are "guaranteed" that the system won't oops.
What is left is the filesystem integrity and delayed writes. Mounting with "sync" is harmful and slow, but I think we do not delay writes these days. So, it should be safe to look at LEDs and pull the device when they stop flashing.
Seriously, people, USB devices are designed to be hotpluggable.
-- Pete
Camilo,
I am not really sure if it is the same problem but I guess you might want to take a look at this bug report: [] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144551
And if it is relevant to you, please drop a comment.
Cheers,
-William
El vie, 06-01-2006 a las 10:18 +0000, Cam escribió:
Hi
First, never yank a mounted USB device.
Something that has been bothering me for a while, what is responsible for detecting and mounting USB devices on Fedora?
The reason I ask is that I'd like to make sure that what I consider reasonable mount options are used, including noatime and shortname=win95 (I have a FAT based mp3 player that by default mounts but is unusable due to the default shortname setting)
I would like to reconfigure it and if code changes are necessary to allow configurability then I might still be tempted. So please point me in the direction of something relevant...
-Cam
-- camilo@mesias.co.uk <--
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! Reg�strate ya - http://correo.yahoo.com.mx/
On Thu, Jan 05, 2006 at 02:18:37PM -0500, John (J5) Palmieri wrote:
As for drives opening I would guess we could listen for the button press and do an unmount/eject. The question is do we get eject button signals from the kernel.
Or from the hardware. Late ATA supports polling and the like for button changes but AFAIK nobody ever implemented the user space polling tool and most drives don't support it
On Fri, 2006-01-06 at 06:51 -0500, Alan Cox wrote:
On Thu, Jan 05, 2006 at 02:18:37PM -0500, John (J5) Palmieri wrote:
As for drives opening I would guess we could listen for the button press and do an unmount/eject. The question is do we get eject button signals from the kernel.
Or from the hardware. Late ATA supports polling and the like for button changes but AFAIK nobody ever implemented the user space polling tool and most drives don't support it
Since a recent release, we poll for this in HAL and emit a signal on the system message bus when the button is pressed. I believe recent version of gnome-volume-manager is able to intercept the signal and attempt the unmount / eject dance.
Of course, the unmount operation might fail if one or some processes have open files on the media; I don't think g-v-m yet spams the user with a dialog a'la "The application Foo is preventing ejection of your optical disc" but I wouldn't be surprised if it does.
Yes, it only works on some drives.
David