Only that no file was corrupted, but the catalog extends. I don't exactly know what it is, but it sounds like part of the disk catalog.
In a Unix-like environment, sure as hell no higher-level application should be allowed to write directly to the disk catalog (that was not even the case with the Apple ][ 20 years ago).
Smircle, we all realize that you're upset because you've had a trying time with your machine -- that's understandable. But it's extraordinarily presumptuous to make sweeping accusations about OS X in the manner you have. I believe I'm not exaggerating here when I say OS X is rock solid for a great many of its users. Your data is far safer with OS X than it would be with the classic Mac OS.
I'm not a programmer, and I'm not going to feign one, but it doesn't sound like you're one, either. So how did you come to the specific conclusion that HFS+ is at fault? If you had analyzed the crash logs and had specific proof that the filesystem caused the error, that would be one thing. Yet, it appears that you came up with that explanation because it sounded good to you, not because it was necessarily valid. I apologize if I've viewed the situation incorrectly, but that's how it seems. And btw, surely you must be joking about the Apple II, which of course had no true OS to speak of.
So how did you come to the specific conclusion that HFS+ is at fault?
It is not HFS+ (which is just a format like JPEG is an image format) but the specific implementation that is in MacOS-X (like QuickTime has an implementation of a JPEG-renderer).
I still hold that the implementation of the HFS-layer (driver if you will) is likely faulty.
Quote:
If you had analyzed the crash logs and had specific proof that the filesystem caused the error, that would be one thing. Yet, it appears that you came up with that explanation because it sounded good to you, not because it was necessarily valid.
Point is: there was no crash. The FS got corrupted through 1.5 month of perfectly normal operation. There are only two possible culprits:
- the OS
- the hardware.
Of course, I cannot rule out the possibility that there is a faulty transistor somewhere in this 'book. BUT, I have just checked back with my mates on IRC, and two had exactly the same problems over the last year. Both (like me, even if I say so myself) experienced and seasoned Mac-users.
I would not have posted if I had not seen 5 - 7 people who had their FSses dying on them before.
Quote:
And btw, surely you must be joking about the Apple II, which of course had no true OS to speak of.
Oh, it had, it had... for it's 12KB resident size, it was a miracle... but that was long ago :-)
BTW: Kickaha - I have just booted the 'book into 9 to gauge pro it - to no avail, my RAM seems just fine.
Kickaha and Amorph couldn't moderate themselves out of a paper bag. Abdicate responsibility and succumb to idiocy. Two years of letting a member make personal attacks against others, then stepping aside when someone won't put up with it. Not only that but go ahead and shut down my posting priviledges but not the one making the attacks. Not even the common decency to abide by their warning (afer three days of absorbing personal attacks with no mods in sight), just shut my posting down and then say it might happen later if a certian line is crossed. Bullshit flag is flying, I won't abide by lying and coddling of liars who go off-site, create accounts differing in a single letter from my handle with the express purpose to decieve and then claim here that I did it. Everyone be warned, kim kap sol is a lying, deceitful poster.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Smircle: I should have stated that Gauge Pro picked up the error about one run out of every 4. It was there, it was just... transient. I at first thought it was a seating issue from thermal expansion in (ta-da) my laptop, but it turned out that the RAM was indeed faulty after further testing.
Try reseating the RAM, and your drive cables. As AirSluf said, because your iBook is being moved around, etc, it's subject to a lot of forces that desktops aren't, and will exhibit transient problems due to loose connectors, etc. It may not feel loose to you, but even a tiny amount of movement in a RAM slot or drive cable can cause intermittent problems.
FWIW, I had a IIcx back in the day, that would lock up at 42 minutes of operation, give or take a few seconds. You could almost set your watch by it.
Obviously a software overflow problem, right?
Nuh-uh. There was a microscopic crack in one of the RAM slots, and after almost precisely 42 minutes of heating, it would pop free just enough to cause a hard crash. Took nine months and six trips to the Apple tech to track that one down... because we of course all *knew* that it was a software problem... :P
Smircle: I should have stated that Gauge Pro picked up the error about one run out of every 4. It was there, it was just... transient.
Well I did run gauge pro for some minutes - nothing.
Disturbingly enough, the FS of the computer of another friend of mine just died (some invalid node structure this time). Please tell me I am seeing things...
I posted a fix for overlapped extent allocations (if that's your problem) over at the Genius Bar. It generally is caused by P2P utilities (Acquisition, LimeWire, and BitTorrent have all had this problem).
I posted a fix for overlapped extent allocations (if that's your problem) over at the Genius Bar. It generally is caused by P2P utilities (Acquisition, LimeWire, and BitTorrent have all had this problem).
Quite a corroboration, thanks. And a scary thought, since I had been using LimeWire.
Oh absolutely. If high-level applications like P2P clients are able to corrupt the FS, then the implementation of said FS is faulty.
You know, disk utilities are high-level applications too and they need access to this stuff. Apple provides a more abstracted API for apps that only need access to "regular" files, but it's up to developers to use it.
You know, disk utilities are high-level applications too and they need access to this stuff. Apple provides a more abstracted API for apps that only need access to "regular" files, but it's up to developers to use it.
They are definitely no high-level in the way they access the file system. I have not looked through the code of Limewire et al., but I guess they use ordinary fopen() or new FileOutputStream() in the case of LimeWire.
If you do this, you just should not be able to corrupt the FS, not matter what you do (this is similar to the protected memory in MacOS X in contrast to the unprotected in MacOS 7/8/9).
*And* even more fishy if more than one sort of program is able to ruin stuff this way.
Comments
Originally posted by Smircle
Only that no file was corrupted, but the catalog extends. I don't exactly know what it is, but it sounds like part of the disk catalog.
In a Unix-like environment, sure as hell no higher-level application should be allowed to write directly to the disk catalog (that was not even the case with the Apple ][ 20 years ago).
Smircle, we all realize that you're upset because you've had a trying time with your machine -- that's understandable. But it's extraordinarily presumptuous to make sweeping accusations about OS X in the manner you have. I believe I'm not exaggerating here when I say OS X is rock solid for a great many of its users. Your data is far safer with OS X than it would be with the classic Mac OS.
I'm not a programmer, and I'm not going to feign one, but it doesn't sound like you're one, either. So how did you come to the specific conclusion that HFS+ is at fault? If you had analyzed the crash logs and had specific proof that the filesystem caused the error, that would be one thing. Yet, it appears that you came up with that explanation because it sounded good to you, not because it was necessarily valid. I apologize if I've viewed the situation incorrectly, but that's how it seems. And btw, surely you must be joking about the Apple II, which of course had no true OS to speak of.
Originally posted by Big Mac
So how did you come to the specific conclusion that HFS+ is at fault?
It is not HFS+ (which is just a format like JPEG is an image format) but the specific implementation that is in MacOS-X (like QuickTime has an implementation of a JPEG-renderer).
I still hold that the implementation of the HFS-layer (driver if you will) is likely faulty.
If you had analyzed the crash logs and had specific proof that the filesystem caused the error, that would be one thing. Yet, it appears that you came up with that explanation because it sounded good to you, not because it was necessarily valid.
Point is: there was no crash. The FS got corrupted through 1.5 month of perfectly normal operation. There are only two possible culprits:
- the OS
- the hardware.
Of course, I cannot rule out the possibility that there is a faulty transistor somewhere in this 'book. BUT, I have just checked back with my mates on IRC, and two had exactly the same problems over the last year. Both (like me, even if I say so myself) experienced and seasoned Mac-users.
I would not have posted if I had not seen 5 - 7 people who had their FSses dying on them before.
And btw, surely you must be joking about the Apple II, which of course had no true OS to speak of.
Oh, it had, it had... for it's 12KB resident size, it was a miracle... but that was long ago :-)
BTW: Kickaha - I have just booted the 'book into 9 to gauge pro it - to no avail, my RAM seems just fine.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Try reseating the RAM, and your drive cables. As AirSluf said, because your iBook is being moved around, etc, it's subject to a lot of forces that desktops aren't, and will exhibit transient problems due to loose connectors, etc. It may not feel loose to you, but even a tiny amount of movement in a RAM slot or drive cable can cause intermittent problems.
FWIW, I had a IIcx back in the day, that would lock up at 42 minutes of operation, give or take a few seconds. You could almost set your watch by it.
Obviously a software overflow problem, right?
Nuh-uh. There was a microscopic crack in one of the RAM slots, and after almost precisely 42 minutes of heating, it would pop free just enough to cause a hard crash. Took nine months and six trips to the Apple tech to track that one down... because we of course all *knew* that it was a software problem... :P
Originally posted by Kickaha
Smircle: I should have stated that Gauge Pro picked up the error about one run out of every 4. It was there, it was just... transient.
Well I did run gauge pro for some minutes - nothing.
Disturbingly enough, the FS of the computer of another friend of mine just died (some invalid node structure this time). Please tell me I am seeing things...
Originally posted by Malokata
I posted a fix for overlapped extent allocations (if that's your problem) over at the Genius Bar. It generally is caused by P2P utilities (Acquisition, LimeWire, and BitTorrent have all had this problem).
Quite a corroboration, thanks. And a scary thought, since I had been using LimeWire.
Here is the Genius bar link for those who care.
Originally posted by Smircle
Quite a corroboration, thanks. And a scary thought, since I had been using LimeWire.
Here is the Genius bar link for those who care.
What? No blame on HFS+?
Originally posted by JLL
What? No blame on HFS+?
Oh absolutely. If high-level applications like P2P clients are able to corrupt the FS, then the implementation of said FS is faulty.
Dumbass sales guy posing as a technician replaced the RAM, we almost missed Apple's DOA period because of it
It could be anything, in other words.
And what's Apple going to do? Run every single application in a sandbox to stop them messing up the system?
Barto
Originally posted by Smircle
Oh absolutely. If high-level applications like P2P clients are able to corrupt the FS, then the implementation of said FS is faulty.
You know, disk utilities are high-level applications too and they need access to this stuff. Apple provides a more abstracted API for apps that only need access to "regular" files, but it's up to developers to use it.
Originally posted by Whisper
You know, disk utilities are high-level applications too and they need access to this stuff. Apple provides a more abstracted API for apps that only need access to "regular" files, but it's up to developers to use it.
They are definitely no high-level in the way they access the file system. I have not looked through the code of Limewire et al., but I guess they use ordinary fopen() or new FileOutputStream() in the case of LimeWire.
If you do this, you just should not be able to corrupt the FS, not matter what you do (this is similar to the protected memory in MacOS X in contrast to the unprotected in MacOS 7/8/9).
*And* even more fishy if more than one sort of program is able to ruin stuff this way.