I only know Norton (more likely to cause corruption than fix it, it
seems) and DiskWarrior (which can fix things fsck can't, apparently by completely rebuilding the tree structures).
I like to call it "Hey, spend money here, too!" The subtitle is
something like "Our hard disk tools are in no way unique, but if you're
on a spending spree we can always use the cash."
Does it actually do anything useful that Diskwarrior can't? Last time I touched TTP it was pretty useless.
In article <3efd2580$0$1092$3c090ad1@news.plethora.net>,
Seebs <seebs@plethora.net> wrote:
Wasn't someone just pointing out that a full B-tree can result in the >>directory for a disk being overwritten if the disk is too full, and that >>this has been the case since the 80's?
Somoene _claimed_ that.
I'd be interested in seeing the "full disk can corrupt directory tree" thing >>explained or debunked.
I'd like to see it substantiated. There have been BUGS which caused >corruption in a near-full disk, but I never heard it being claimed as
a design problem. Nor have I heard (except for the one claim here) of
such bugs being present in Mac OS 9 or OS X.
Err, no, it isn't, except in name.
Reformatting eliminates a whole host of ills. Corrupt file systems
are only one of them. The major one is it eliminates variables (such
as installed programs and patches) which the user has "forgotten"
about.
True on MacOS as well, as far as I know. It's if it doesn't come out
clean you may have problems. And I have seen Sun systems which
wouldn't fsck clean.
By contrast, HFS+ has spawned three third-party disk utilities I can think of,
I only know Norton (more likely to cause corruption than fix it, it
seems) and DiskWarrior (which can fix things fsck can't, apparently by >completely rebuilding the tree structures).
Huh? Go back up the thread. I said "HFS+ is a derivative of HFS". Someone said it wasn't. I asked for substantiation, and instead of getting any kind of response, got a sudden detour into other topics.
Seebs wrote:
Nothing's perfect. However, this particular sub-thread ofAssertion failed.
discussion has only to do with whether or not HFS+ is clearly
a derivative of HFS, and it is.
The person who said that HFS+ is not related to HFS in any way made an obviously silly claim, with no substantiation; in the particular part of his post I was referring to in the above paragraph, that was the topic of discussion.
Most of the time, when a filesystem utility written for one filesystem can read the filesystem layout of another filesystem *by accident*, it is a reasonable conclusion that they are in some way related.
In article <LqKdncWZN7Gr4p2iXTWc-w@speakeasy.net>,
Matthew Russotto <russotto@grace.speakeasy.net> wrote:
In article <3efd2580$0$1092$3c090ad1@news.plethora.net>,
Seebs <seebs@plethora.net> wrote:
Wasn't someone just pointing out that a full B-tree can result in the >>>directory for a disk being overwritten if the disk is too full, and that >>>this has been the case since the 80's?
Somoene _claimed_ that.
Well, yes. And it's hard to predict, because the Mac world is full of
cargo cult debugging practices, like resetting PRAM on any and all occasions, >and reformatting disks, and so on...
I'd be interested in seeing the "full disk can corrupt directory tree" thing >>>explained or debunked.
I'd like to see it substantiated. There have been BUGS which caused >>corruption in a near-full disk, but I never heard it being claimed as
a design problem. Nor have I heard (except for the one claim here) of
such bugs being present in Mac OS 9 or OS X.
Indeed. On the other hand, I've rarely-if-ever had a particularly crowded >HFS disk, and I don't have any spares I wouldn't mind corrupting to test. :)
Anyway, it's the kind of thing I sort of expect from Apple's half-assed >engineering approach to well-understood problems. This was the company that >gave us the VM system which looked exactly like what you would get from a >college kid who'd never seen VM done before; I have very little respect for >the low-level technical expertise that built stuff like HFS.
If by other utilities you mean Norton -- yes, because it finds stuff
that isn't there. DiskWarrior can fix stuff fsck_hfs can't, but I haven't
Some of which did once work. And some of which appear to do something
(like "Repair Permissions") even when they don't.
In article <3f03d927$0$1098$3c090ad1@news.plethora.net>,
Seebs <seebs@plethora.net> wrote:
Well, yes. And it's hard to predict, because the Mac world is full of >>cargo cult debugging practices, like resetting PRAM on any and all occasions, >>and reformatting disks, and so on...
Some of which did once work. And some of which appear to do something
(like "Repair Permissions") even when they don't.
Anyway, it's the kind of thing I sort of expect from Apple's half-assed >>engineering approach to well-understood problems. This was the company that >>gave us the VM system which looked exactly like what you would get from a >>college kid who'd never seen VM done before; I have very little respect for >>the low-level technical expertise that built stuff like HFS.
Have you looked into the HFS+ structures? Or are you just using your >prejudices to confirm themselves?
In article <3f03d9ae$0$1100$3c090ad1@news.plethora.net>,
seebs@plethora.net (Seebs) wrote:
Huh? Go back up the thread. I said "HFS+ is a derivative of HFS". Someone >> said it wasn't. I asked for substantiation, and instead of getting any kind >> of response, got a sudden detour into other topics.
Only in your mind. The rest of us were discussing the topic in the
Subject line.
Two assertions failed in that one.
What an old HFS utility will find is not the HFS+ volume, but rather the
HFS wrapper. This wrapper exists to prevent older versions of the Mac OS >from finding that an HFS+ volume has no files on it and should be >reformatted. It does not mean that the file systems are compatible, just >that a few HFS control blocks are created (and are otherwise never
changed) so that old utlities can find them and (hopefully) muck with
*them* and not the HFS+ components.
They both have B-trees and resource and data forks. But then again,
so does NTFS. HFS+ and HFS are substantially different file systems.
One is not "a bag on the side of" the other.
Oh, it happens - but on MacOS, it is possible for Disk First Aid to find >>nothing wrong, but other utilities to find something wrong.
If by other utilities you mean Norton -- yes, because it finds stuff
that isn't there. DiskWarrior can fix stuff fsck_hfs can't, but I haven't >heard of it finding stuff fsck_hfs can't.
If you bypass the normal file APIs and touch the file system directly >though, HFS+ and HFS are radically different. Even though they both use >B-trees and have more than 1 fork. They are so different that a Mac OS
8.0 system will utterly fail to recognise a HFS+ disk---or at least
would do so if the HFS 'shim' were not there, containing a file that
says "nothing to see here, move along please".
I would say that the culprit was Mac OS 9 vs Mac OS X. I don't see a lot
of problems with any file system under Mac OS X. UFS isn't supported
under Mac OS 9 so there isn't really a basis for comparison of HFS and
HFS+ vs anything else. I will observe that I had fewer problems (under
Mac OS <=9) with HFS+ than I did with HFS though.
To return to the subject of this thread: it has been claimed that UFS is >'obviously' superior to HFS+. I think we have comprehensively proved
that there is nothing 'obvious' about it. On the contrary, on Mac OS X,
HFS+ is 'obviously' to be preferred for most users.
Implementations aside, UFS may be superior to HFS+, or vice versa.
That's not been established. However, if you need rich metadata or
mutiple forks, UFS is not the answer (though NTFS might be). (And I see
that it's been reported that Panther supports NTFS.)
Huh? Go back up the thread. I said "HFS+ is a derivative of HFS". Someone
You directly quoted and responded to the claim that HFS+ is related to HFS. It was part of the discussion.
Okay. And utilities which don't do this... do what exactly? They chew through the filesystem, and do substantial damage to it.
Oh, wait--I do have a clue: HFS+ is a pretty stupid name
for something that's _not_ a derivative of HFS.
Seebs wrote:
And here we are folks, the post in which Steven Fisher clearly responded
to a claim about the relationship between HFS+ and HFS - by admitting that >> he could not refute the claim that they are related.
That was not the failed assertion.
You missed the intended relevance of the claim, which is that disk utilities shouldn't even have looked at a disk which wasn't of at least a *vaguely* related format.
For instance, is MacOS 9 a "derivative" of MacOS 7? Of MacOS 6? By the time you've gone from OS 6 to OS 9, you've replaced nearly everything.
Fair enough, that was a solid overstatement on my part. I still say they're "related".
Huh? Go back up the thread. I said "HFS+ is a derivative of HFS". Someone
I haven't a clue whether that's true.
Oh, wait--I do have a clue: HFS+ is a pretty stupid name
for something that's _not_ a derivative of HFS.
One uses another as a wrapper to provide some volume information.
In article <r7GcnV6E_elI4ZmiXTWc-w@speakeasy.net>,
Matthew Russotto <russotto@grace.speakeasy.net> wrote:
They both have B-trees and resource and data forks. But then again,
so does NTFS. HFS+ and HFS are substantially different file systems.
One is not "a bag on the side of" the other.
Fair enough, that was a solid overstatement on my part. I still say they're >"related".
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 717 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 21:22:01 |
| Calls: | 9,153 |
| Calls today: | 1 |
| Files: | 5,288 |
| D/L today: |
92 files (29,978K bytes) |
| Messages: | 465,704 |
| Posted today: | 2 |