Ok, how the HELL do you eject a cd from a Mac

[Ron_Tomkins]

Slot-loading, or tray drive (ie, does a tray pop out when you eject the drive, or is there just a slot you insert the disc into)?

There's just a slot I insert the disc into.

I use a MacBook Pro

 

[Verde]

Do PC laptops have a mechanical button for ejecting optical discs (sincere, not rhetorical question)?

I can't speak for all laptops, of course, but my work-supplied Dell D630 has a little hole on the DVD drive.
I just put a CD in there, disconnected the power, and prodded the hole with a small screwdriver. The drive opened enough to remove the disk.

V.

 

[CFLarsen]

However, the CD-drives in PC's can be blocked too from opening! The software can instruct the drive to ignore a push on the "open" button.

You may not see this behaviour with Windows, but you can see it with Linux. Linux - as every UNIX - requires that a disk (or partition) be mounted before the filesystem on it can be used; and likewise, that it be unmounted before you remove the disk from your system.

(If you want to see a reason for this, try it with a floppy. Copy a 1MB file to the floppy. That happens instantaneous, you won't hear the floppy - all writes are still in the kernel cache. Then when you issue the unmount command, you'll hear actually write the file to floppy.)

So, when you put in a CD and mount it under Linux, the Linux kernel will issue a command to the drive that it must disable the "open" button. All CD-drives, except for the very early IDE drives, do this. You can simply check this by having a file from the CD in use and then push the button. It won't open.

So that "software can be faulty" argument doesn't hold. And on a Mac - with MacOS, another flavour of UNIX as OS - the same reasoning as for Linux applies - the software would logically need to disable the button while the CD is in use. So why have a button at all?

For one simple reason: Software does not always work.

Note: An electronic solution is not always a software solution. It could be pure circuitry. As long as there's power in the battery, it could work, whether the CPU and hard drive work or not.

As long...yes. Perhaps.

As far as physical buttons are concerned, a non-slot-loading drive will have a paperclip button. This is a purely physical mechanism, and is sane. Anything that doesn't have this mechanism will end in trouble if a fault develops, and the only way around it would be to remove and disassemble the drive.
On a PC, this can take 10 minutes - on a mac, this can take longer than the remaining time in the universe before heat death. Trust me.

Macs are pretty, and generally good machines, but if you had the choice between pretty and useable...

Exactly.

For those of you with slot-loading Macs--how often do you have problems ejecting discs? AFAIK it's not a significant issue.

By the way, most if not all new Macs have physical eject buttons on the keyboards. And again, is there any evidence that slot-loading Macs have more stuck-CD problems than non-slot-loading computers? Are we certain that it's a significant problem not having an eject button on the actual drive itself?

It isn't a question of how often it happens, but a question of what you are going to do when it happens.

Murphy's law was written for this type of flaws.

 

[ddt]

However, the CD-drives in PC's can be blocked too from opening! The software can instruct the drive to ignore a push on the "open" button.

You may not see this behaviour with Windows, but you can see it with Linux. Linux - as every UNIX - requires that a disk (or partition) be mounted before the filesystem on it can be used; and likewise, that it be unmounted before you remove the disk from your system.

(If you want to see a reason for this, try it with a floppy. Copy a 1MB file to the floppy. That happens instantaneous, you won't hear the floppy - all writes are still in the kernel cache. Then when you issue the unmount command, you'll hear actually write the file to floppy.)

So, when you put in a CD and mount it under Linux, the Linux kernel will issue a command to the drive that it must disable the "open" button. All CD-drives, except for the very early IDE drives, do this. You can simply check this by having a file from the CD in use and then push the button. It won't open.

So that "software can be faulty" argument doesn't hold. And on a Mac - with MacOS, another flavour of UNIX as OS - the same reasoning as for Linux applies - the software would logically need to disable the button while the CD is in use. So why have a button at all?

For one simple reason: Software does not always work.

Your answer does not address the issue I brought up at all. Is this Claus-I-won't-admit-to-be-wrong-mode, or is did you just not get my explanation?

The issue of disabling the open-button is one of data integrity. The OS's kernel will not let you remove a disk/partition/volume/... as long as it's in use. And I trust the OS's kernel - Windows included - much more than a human being in administering such things truthfully. Now the issue is less pressing with CD's/DVD's than with floppies - you can't use them read/write - I think the principle still holds that you should not be able to eject them while still in use.

I'll gladly tackle your "software does not always work" argument: that's indeed what the paperclip-hole is for. An emergency measure, not a simple, innocently looking open-button you can press at any time.

 

[CFLarsen]

Your answer does not address the issue I brought up at all. Is this Claus-I-won't-admit-to-be-wrong-mode, or is did you just not get my explanation?

You asked a question. I answered it.

The issue of disabling the open-button is one of data integrity. The OS's kernel will not let you remove a disk/partition/volume/... as long as it's in use. And I trust the OS's kernel - Windows included - much more than a human being in administering such things truthfully. Now the issue is less pressing with CD's/DVD's than with floppies - you can't use them read/write - I think the principle still holds that you should not be able to eject them while still in use.

I know there is a question of data integrity. But you have to understand that one thing overrides that:

The user must always be in full control.

If he pushes the button, that means he wants to open the drive. He takes specific action - action that he normally performs when he inserts/removes disks from the drive. The button is near the slot, it makes sense that it is there, rather than for the user to look for some icon or function more-or-less hidden away on his monitor.

Can he push the button by accident? Sure! Can he lose data that way? Sure! Is there a guaranteed way that he won't ever lose data? Nope!

The question is: Who is in control here, the user or the software? Both are error-prone, but it is far better to have the user make his own mistakes, than to have the computer take control.

By default, the software should not prevent the user from pushing the button. The software should only step in with a warning in case all data hasn't been saved. Otherwise, the user must be free to do whatever he wants.

I'll gladly tackle your "software does not always work" argument: that's indeed what the paperclip-hole is for. An emergency measure, not a simple, innocently looking open-button you can press at any time.

No, that's what the button should be for. The paperclip-hole should be for ultra-emergencies, to circumvent the lock in case the button doesn't work.

If you can open the drive at any time anyway, why have a software lock on the button?

Oh, incidentally: My professional field of expertise is usability and user interface design.

 

[Arthur Denton]

ummmmmmmmmmmmmmm...wha?

May the lord help me figure it too

 

[ddt]

I know there is a question of data integrity.

OK. Ever wondered when writing to a floppy if it was safe to remove it?

But you have to understand that one thing overrides that:

The user must always be in full control.

I don't agree. root must be in full control. the luser is an ignorant fool who is only (unknowingly) intent on compromising the system.

The correct order of actions when using a CD or DVD is:

1. physically insert the disk
2. mount the disk
3. use the data on the disk
4. unmount the disk
5. physically remove the disk

It is an unfortunate misunderstanding on the part of Microsoft that it doesn't have steps 2 and 4. Somehow they assume that every disk/partition I have in my system I also actually want to use; quod non. Missing step 4 means a compromise of data integrity for all (writable) removable media such as floppies and USB sticks.

As you see, there is nothing wrong with blocking the action of the open button of the drive as long as you haven't performed step 5. Steps 4&5 are also clearly the symmetrical actions of steps 1&2, and, as to be expected, in reverse order.

If he pushes the button, that means he wants to open the drive. He takes specific action - action that he normally performs when he inserts/removes disks from the drive. The button is near the slot, it makes sense that it is there, rather than for the user to look for some icon or function more-or-less hidden away on his monitor.

See below.

Can he push the button by accident? Sure! Can he lose data that way? Sure! Is there a guaranteed way that he won't ever lose data? Nope!

Not on a system I'd administer. The sysadmin - yes, but s/he knows this and can find out which application is blocking the unmount by typing something like

# fuser -m /media/mydisk​

But the sort of luser-friendliness you advocate is precisely why the average home Windows PC is infested with viruses, worms and other kind of malware.

The question is: Who is in control here, the user or the software? Both are error-prone, but it is far better to have the user make his own mistakes, than to have the computer take control.

It's clear we have a different outlook about which one is more error-prone.

By default, the software should not prevent the user from pushing the button. The software should only step in with a warning in case all data hasn't been saved. Otherwise, the user must be free to do whatever he wants.

I did a little test on two of my machines: my Linux desktop (Fedora Core 6) and my iBook G4 with MacOS 10.3 "Panther".

First Fedora Core 6 with a Gnome desktop. After inserting the DVD, it detects it and automatically mounts the disk. Pushing the open button on the drive makes it automatically unmount the disk and open the tray. Right-clicking on the icon on the desktop and choosing "Eject" did the same.

Then I inserted the DVD and subsequently did a 'cd' in a terminal-window to the root-directory of the disk. Both actions outlined above (pressing the open button, resp. right clicking the desktop icon) resulted in a pop-up with a message like: "Could not unmount volume. Try quitting applications".

Secondly MacOS 10.3. My iBook has a slot loading drive, so it has no open button. I tried (1) to click the "eject" icon in a Finder window, (2) to Ctrl-Click the desktop icon, and (3) to press fn-F12. All cases resulted, of course, in ejecting the disk.

Then I inserted the DVD and did a 'cd' in a terminal-window to the root-directory of the disk. Cases (1) and (2) both led to a pop-up window with the message: "The disk "Fedora 9" is in use and could not be ejected. Try quitting applications and try again". Case (3) did not result in any action or pop-up window.

From a usability standpoint, I'm satisfied with this behaviour in general - except for case (3) with MacOS, and I couldn't test what MacOS does when there is an eject button. But in the other cases - it gives me a message that it is unsafe to eject the disk and I should first solve that.

No, that's what the button should be for. The paperclip-hole should be for ultra-emergencies, to circumvent the lock in case the button doesn't work.

Does that mean we agree? I'd qualify the case where you can't kill the apps that use the disk as an ultra-emergency. There's always a text-terminal you can log into as root and kill them, isn't there?

If you can open the drive at any time anyway, why have a software lock on the button?

As long as there's nothing in the drive, or there is a CD in it that is not mounted (which is possible), it is safe to open it. As soon as you have the disk in use, it is not.

Oh, incidentally: My professional field of expertise is usability and user interface design.

My expertise is UNIX/Linux administration. Does it show?

 

[CFLarsen]

OK. Ever wondered when writing to a floppy if it was safe to remove it?

See previous post.

I don't agree. root must be in full control. the luser is an ignorant fool who is only (unknowingly) intent on compromising the system.

It is thanks to this kind of thinking that I will never go hungry.

The correct order of actions when using a CD or DVD is:

1. physically insert the disk
2. mount the disk
3. use the data on the disk
4. unmount the disk
5. physically remove the disk

It is an unfortunate misunderstanding on the part of Microsoft that it doesn't have steps 2 and 4. Somehow they assume that every disk/partition I have in my system I also actually want to use; quod non. Missing step 4 means a compromise of data integrity for all (writable) removable media such as floppies and USB sticks.

As you see, there is nothing wrong with blocking the action of the open button of the drive as long as you haven't performed step 5. Steps 4&5 are also clearly the symmetrical actions of steps 1&2, and, as to be expected, in reverse order.

The idea of "mounting" a disk will be utterly incomprehensible to the average user.

Not on a system I'd administer. The sysadmin - yes, but s/he knows this and can find out which application is blocking the unmount by typing something like

# fuser -m /media/mydisk​

This is completely gibberish to the user. Why do you insist that he communicates with the computer in a manner that is more computer-centric than human-centric?

Do you write low-level code every time you communicate with a computer?

But the sort of luser-friendliness you advocate is precisely why the average home Windows PC is infested with viruses, worms and other kind of malware.

No, the average home Windows PC is infested with viruses, worms and other kind of malware because Windows PCs are by far the most widespread configuration among personal computers.

Not only are you ignorant of usability, you are also spreading false information.

It's clear we have a different outlook about which one is more error-prone.

You could well argue that users are more error-prone, but the thing you are missing is that, even if the user is the cause of the error, the user was still in control. There is nothing as frustrating as having control taken away from you.

It is clear that you view computers from a technician's point of view, while I view them from the user's point of view. Which view do you think should govern how people use computers?

I did a little test on two of my machines: my Linux desktop (Fedora Core 6) and my iBook G4 with MacOS 10.3 "Panther".

I don't care. You are clearly not a common computer user.

Does that mean we agree? I'd qualify the case where you can't kill the apps that use the disk as an ultra-emergency. There's always a text-terminal you can log into as root and kill them, isn't there?

No, we don't agree. The button is there for every day use, the paperclip hole is for ultra-emergencies.

As long as there's nothing in the drive, or there is a CD in it that is not mounted (which is possible), it is safe to open it. As soon as you have the disk in use, it is not.

See above.

My expertise is UNIX/Linux administration. Does it show?

Yes, it does. Stick to that, and leave usability to the professionals. You should certainly not lecture people on how stupid they are, just because they don't have your technical expertise - e.g., by calling them "lusers".

 

[jimtron]

The user must always be in full control.

If he pushes the button, that means he wants to open the drive. He takes specific action - action that he normally performs when he inserts/removes disks from the drive. The button is near the slot, it makes sense that it is there, rather than for the user to look for some icon or function more-or-less hidden away on his monitor.

Can he push the button by accident? Sure! Can he lose data that way? Sure! Is there a guaranteed way that he won't ever lose data? Nope!

I'm sure there are many sophisticated computer users here. But the typical computer user needs to be, and I believe wants to be, saved from themselves. I would be willing to wager that if you gave the average computer user the choice of a) having the power and control of ejecting a disc anytime, which could result in data loss or other problems, vs. b) you use the GUI or eject button on your keyboard, which will eject the disc only if it's safe to do so, many more people would choose "b." I find that most computer users don't understand their systems well at all, and are afraid of screwing things up.

 

[CFLarsen]

I'm sure there are many sophisticated computer users here. But the typical computer user needs to be, and I believe wants to be, saved from themselves. I would be willing to wager that if you gave the average computer user the choice of a) having the power and control of ejecting a disc anytime, which could result in data loss or other problems, vs. b) you use the GUI or eject button on your keyboard, which will eject the disc only if it's safe to do so, many more people would choose "b."

The issue of data loss is something the system should handle - in a way that doesn't take away control from the user. The overriding issue is control: Control that it won't take a long education to exert.

I find that most computer users don't understand their systems well at all, and are afraid of screwing things up.

Yes, they are, and no, they don't understand their "systems" well at all. But the number of computer users has only grown to the number it is today because we are not writing

# fuser -m /media/mydisk​

anymore. We press a button(!), the "cup holder" slides out, and, lo and behold: Here's a place we can put our disk! Then, the system recognizes the disk - but leaves it to the user to control when he can get the disk back again.

The user doesn't give a damn how the system is supposed to recognize the disk - and why should he? That is what computers are for. But they are afraid, because too often, their computer runs them - without explaining what it is "they" are doing "wrong".

 

[ktesibios]

We had a very similar problem with one of the **** iMacs in one of the client lounges at work. The recovery procedure was as follow:

1. Curse vilely.
2. Take computer to Apple repair shop and have them extricate the CD-ROM.
3. Buy computer back from Apple repair shop.
4. Use cheap labelmaker to make label reading "DO NOT TRY TO USE THE CD-ROM DRIVE. IT WILL NOT EJECT YOUR CD".
5. Stick label over CD-ROM loading slot on computer.
6. Curse even more vilely.

 

[jimtron]

We had a very similar problem with one of the **** iMacs in one of the client lounges at work. The recovery procedure was as follow:

1. Curse vilely.
2. Take computer to Apple repair shop and have them extricate the CD-ROM.
3. Buy computer back from Apple repair shop.
4. Use cheap labelmaker to make label reading "DO NOT TRY TO USE THE CD-ROM DRIVE. IT WILL NOT EJECT YOUR CD".
5. Stick label over CD-ROM loading slot on computer.
6. Curse even more vilely.

That's a broken computer issue, not a slot-loading vs tray-loading, or "no button" issue, right? Just to clarify. Macs and PCs both break sometimes, or don't behave as they're supposed to.

 

[CFLarsen]

That's a broken computer issue, not a slot-loading vs tray-loading, or "no button" issue, right? Just to clarify. Macs and PCs both break sometimes, or don't behave as they're supposed to.

Well, yes and no.

In the case of them not "behaving" (see how quickly we attribute human nature to machines?), the question is why they don't "behave".

In the case of the OP, it is a case of bad design if the computer locks the disk inside the drive if it can't read it.

In the words of Ian Malcolm, Jurassic Park:

God help us; we're in the hands of engineers.

 

[elgarak]

Well, yes and no.

In the case of them not "behaving" (see how quickly we attribute human nature to machines?), the question is why they don't "behave".

In the case of the OP, it is a case of bad design if the computer locks the disk inside the drive if it can't read it.

In the words of Ian Malcolm, Jurassic Park:

I think you're jumping to a wrong conclusion, which you cannot based on the sketchy anecdote (Based on what was written in this thread, I fail to understand what has happened to the OP).

In my experience, Apple design is far from bad, and with a functioning optical drive a locked, unreadable disk is quite unlikely. The disk should have been ejectable with the eject button of the OP's MacBook Pro without reboot, but as I said, the report is too sketchy to be completely sure.

There's also a quite common experience of Windows-trained switchers that happened a few times to myself: Windows trained us to think too complicated. I found myself a few times in situations where I asked myself a similar question to the OP: How the heck do you....? I looked and searched for a Windows-like function the Mac did not have. When I finally found out how to do it, the solution was in ALL CASES very simple and right before me all the time.

 

[Mercutio]

Well, yes and no.

In the case of them not "behaving" (see how quickly we attribute human nature to machines?)

Do you really mean to suggest that only humans can "behave"?

Cos you'd be wrong.

 

[CFLarsen]

I think you're jumping to a wrong conclusion, which you cannot based on the sketchy anecdote (Based on what was written in this thread, I fail to understand what has happened to the OP).

It is based on there being no button. I seriously doubt that Ron Thomkins couldn't figure out what the button was there for.

There's also a quite common experience of Windows-trained switchers that happened a few times to myself: Windows trained us to think too complicated. I found myself a few times in situations where I asked myself a similar question to the OP: How the heck do you....? I looked and searched for a Windows-like function the Mac did not have. When I finally found out how to do it, the solution was in ALL CASES very simple and right before me all the time.

That goes both ways: Moving from one to another is a confusing experience.

Macs may do a lot for you, but you also lose a lot of control.

Do you really mean to suggest that only humans can "behave"?

Cos you'd be wrong.

As I wrote, I was talking about human behavior.

 

[Mercutio]

As I wrote, I was talking about human behavior.

As you wrote, you were talking about "human nature". (Go ahead, read it--it's still there.) Implying, as I said, that "behaving" (the quotes were yours) is unique to human nature. Which, of course, it is not. Heck, even computers behave, and misbehave. Take a look at Dictionary.com, and you will find the very first example is "[t]he ship behaves well", and the third is "[t]his plastic behaves strangely under extreme heat or cold."

Why you would be talking about human behavior when Jimtron was speaking of computer behavior is a bit beyond me, as well. But whatever it takes for you to avoid admitting you were wrong....

 

[CFLarsen]

As you wrote, you were talking about "human nature". (Go ahead, read it--it's still there.) Implying, as I said,

And, as I said, you were wrong to assume that.

that "behaving" (the quotes were yours) is unique to human nature. Which, of course, it is not.

I never said otherwise.

Why you would be talking about human behavior when Jimtron was speaking of computer behavior is a bit beyond me, as well.

It is a bit beyond you that participants can offer their own points in a debate?

But whatever it takes for you to avoid admitting you were wrong....

Here's the thing about debates: jim offered his views, I offered mine. You were so eager to find flaws in my post that you jumped to an unfounded conclusion. And yet, your erroneous conclusion is all due to my "avoiding admitting" I was "wrong"...

Read what I posted again: I was talking about quickly humans look for behavior in machines and attribute that to human behavior. How could I do that, if I argued that machines don't behave?

You were wrong - not I. Let's see you admit that.

 

[Ron_Tomkins]

Originally Posted by elgarak
I think you're jumping to a wrong conclusion, which you cannot based on the sketchy anecdote (Based on what was written in this thread, I fail to understand what has happened to the OP).

It is based on there being no button. I seriously doubt that Ron Thomkins couldn't figure out what the button was there for.

Well sir, if I may jump in, as I already explained: there IS such button. I'm just new to Mac and didn't even notice it. But it's right there on the top right corner of the keyboard. I just didn't notice it was there. However, had I noticed it, I wouldn't have started this thread.

And it's "Tomkins". No H.

 

[GreNME]

As you wrote, you were talking about "human nature". (Go ahead, read it--it's still there.) Implying, as I said, that "behaving" (the quotes were yours) is unique to human nature. Which, of course, it is not. Heck, even computers behave, and misbehave. Take a look at Dictionary.com, and you will find the very first example is "[t]he ship behaves well", and the third is "[t]his plastic behaves strangely under extreme heat or cold."

Why you would be talking about human behavior when Jimtron was speaking of computer behavior is a bit beyond me, as well. But whatever it takes for you to avoid admitting you were wrong....

Why did you bother making this argument?

In the context of this thread, what he said about anthropomorphizing what computers do is accurate. It's a case of computers not doing what we want and instead doing what they are told (in this case, through a faulty software interrupt).

I won't claim to know what the holy grail of convincing CFLarsen he's wrong about something is that I see practically everywhere on the JREF forums, but I think it's getting in the way of rationality in this case.