Chris Barker wrote:
> I had not realised properly that Dan was
> fiddling with someone else's computer ...
Yup -- there's certainly been times when I've been trying to copy
files, had Finder die on me, and hoped that I can get the OS to recover
itself before my wife needed the laptop again.
None of the obvious things worked -- in order of things I tried, the
'stop copying' button in the copy progress window doesn't do anything,
closing the window is impossible because there's no close window, trying
to eject the media by dragging it onto the trashcan doesn't work,
physically removing the device is possible but still leaves everything
else 'running', and the device still shows up both in Finder and in
/Volumes; trying to restart Finder from the Force Quit menu looks like
it ought to work but does nothing, and restarting the whole Mac from
software also doesn't actually do anything because Finder is locked up
in mid-copy, so the Mac can't shut down. (with or without detaching the
device, I hit this problem a few times as I tried different permutations).
Power cycling the hard way is not the most elegant solution, but it's
certainly predictable..
I guess, as Jan points out, "If you have a misbehaving program that
consistently requires a SIGKILL to get rid of it, you should re-boot
often.". That's fair enough -- I just wish Finder wasn't the misbehaving
program in question, or that I had needed to do something more
complicated than copy a file [1] to get it to go wrong.
-- dan
[1] yes, this was trying to read media with bad sectors [2] -- but
that's what error handlers are meant for, I always thought; Windows just
says "invalid data" and stops copying, it doesn't send Explorer into
some weird unrecoverable state that requires a reboot.
Actually, thinking about it, this sort of makes sense -- I'd assume
Finder is written in Objective-C, and one of the main things I dislike
about Objective-C is its attempts to cover up mistakes [3]. If you
deference a null pointer in objC, it just says "hm, I don't think you
really meant to do that", gives up on doing whatever it was doing at the
time, jumps back to the message loop, and keeps on going as if nothing
is wrong -- C++/C will crash, which makes debugging one heck of a lot
easier. That way if your code has bugs in it, it dies -- in objective-C,
a lot of bugs won't make the code die, they'll just make the code have
very unexpected behaviour and take that much longer to debug.
[2] or whatever-it-was that was wrong there
[3] and I'm sure being able to do [nil fooFunction] is very useful in
some situations, I just don't know what those situations _are_.
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|