Comments on: Lost Morning http://www.elharo.com/blog/mac/2007/02/28/lost-morning/ Ranting and Raving Tue, 02 Dec 2008 15:25:59 +0000 http://wordpress.org/?v=2.6.3 By: Zeff Silver http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-478448 Zeff Silver Fri, 08 Aug 2008 11:56:04 +0000 http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-478448 I have had 2 of these Power Mac G5s and have sent them back as they keep locking up i was using tiger OPS. The good news is i have a new mac and its working great, Thanks for a great blog wish i had read this earlier. Thanks for your help. Zeff I have had 2 of these Power Mac G5s and have sent them back as they keep locking up i was using tiger OPS. The good news is i have a new mac and its working great, Thanks for a great blog wish i had read this earlier.
Thanks for your help.
Zeff

]]> By: Mokka mit Schlag » FireWire Killed the Mac http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-52276 Mokka mit Schlag » FireWire Killed the Mac Thu, 08 Mar 2007 14:53:47 +0000 http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-52276 [...] I’m about 99% certain that the various problems I’ve been having on my main desktop Mac lately can all be traced to a misbehaving LaCie d2 external hard drive. (I leave 1% open for the possibility it’s the FireWire cable or controller, but I really don’t think so.) [...] [...] I’m about 99% certain that the various problems I’ve been having on my main desktop Mac lately can all be traced to a misbehaving LaCie d2 external hard drive. (I leave 1% open for the possibility it’s the FireWire cable or controller, but I really don’t think so.) [...]

]]> By: Elliotte Rusty Harold http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-49251 Elliotte Rusty Harold Thu, 01 Mar 2007 12:17:04 +0000 http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-49251 If the problem is indeed a bad block on the hard drive, that still shouldn't hang the process. The read or write should throw an exception that can be responded to in the code. Possibly the read/write should even time out after a certain amount of time. On a higher level, when there is a problem with one file, the remainder of files should continue to copy. Apple has a really bad habit of serializing this, so that when one file fails, the entire operation is blocked, at least until the user explicitly tells it to continue or cancel. If I start copying 500,000 files and go away to watch a movie, I don't want to return to find a dialog telling me file #3 can't be copied, and asking if I want to continue or cancel. Of course, this time I didn't even get that far. It just hung. :-( If the problem is indeed a bad block on the hard drive, that still shouldn’t hang the process. The read or write should throw an exception that can be responded to in the code. Possibly the read/write should even time out after a certain amount of time.

On a higher level, when there is a problem with one file, the remainder of files should continue to copy. Apple has a really bad habit of serializing this, so that when one file fails, the entire operation is blocked, at least until the user explicitly tells it to continue or cancel. If I start copying 500,000 files and go away to watch a movie, I don’t want to return to find a dialog telling me file #3 can’t be copied, and asking if I want to continue or cancel.

Of course, this time I didn’t even get that far. It just hung. :-(

]]> By: bob http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-49034 bob Thu, 01 Mar 2007 02:23:37 +0000 http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-49034 I don't know which platforms John Cowan is referring to, but 64-bit seek addresses are hardly modern or unusual. They've have been supported on many platforms for quite a long time. On Mac OS, this was standard as soon as files could be larger than 4 GB, which was roughly the time of Mac OS 9 and HFS+. Mac OS X has always had 64-bit seek addresses, even if the file-system itself only supports smaller files, e.g. original HFS only supports files with length under 4 GB. Various Unices far older than Mac OS X have long had 64-bit seek addresses, too, even on 32-bit machines. BTW, it may be that the cause of the hang was a defective block on the HD that just happened to be in the large WoW file. A very large file is simply a larger target for When Blocks Go Bad. You're right about the Mac being too stupid to not boot from the corrupted HD, though. That's dumb. Hold down OPTION and it'll come up in the firmware boot-drive selector. At least I think it's OPTION. I can't reboot right now to try it. And I just break out of the OS-install user registration crap. Cmd-Q it and it'll confirm before departing. I don't think I've EVER finished that part of the process, for ANY of the Macs I've owned. I don’t know which platforms John Cowan is referring to, but 64-bit seek addresses are hardly modern or unusual. They’ve have been supported on many platforms for quite a long time.

On Mac OS, this was standard as soon as files could be larger than 4 GB, which was roughly the time of Mac OS 9 and HFS+.

Mac OS X has always had 64-bit seek addresses, even if the file-system itself only supports smaller files, e.g. original HFS only supports files with length under 4 GB.

Various Unices far older than Mac OS X have long had 64-bit seek addresses, too, even on 32-bit machines.

BTW, it may be that the cause of the hang was a defective block on the HD that just happened to be in the large WoW file. A very large file is simply a larger target for When Blocks Go Bad.

You’re right about the Mac being too stupid to not boot from the corrupted HD, though. That’s dumb. Hold down OPTION and it’ll come up in the firmware boot-drive selector. At least I think it’s OPTION. I can’t reboot right now to try it.

And I just break out of the OS-install user registration crap. Cmd-Q it and it’ll confirm before departing. I don’t think I’ve EVER finished that part of the process, for ANY of the Macs I’ve owned.

]]> By: Elliotte Rusty Harold http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-48955 Elliotte Rusty Harold Wed, 28 Feb 2007 18:48:16 +0000 http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-48955 We need to stop using 32-bit ints in filesystem APIs. Nothing less than a 64-bit long is reasonable. <code>java.io.RandomAccessFile</code> did this over ten years ago in JDK 1.0. Have native APIs really not caught up yet? We need to stop using 32-bit ints in filesystem APIs. Nothing less than a 64-bit long is reasonable. java.io.RandomAccessFile did this over ten years ago in JDK 1.0. Have native APIs really not caught up yet?

]]> By: John Cowan http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-48933 John Cowan Wed, 28 Feb 2007 16:50:39 +0000 http://www.elharo.com/blog/mac/2007/02/28/lost-morning/#comment-48933 The obvious problem is that a file larger than 2^32 bytes can't be randomly accessed, only sequentially, unless you use special 64-bit system calls. Not many programs do. The obvious problem is that a file larger than 2^32 bytes can’t be randomly accessed, only sequentially, unless you use special 64-bit system calls. Not many programs do.

]]>