[AppleGirl1990]

I purchased a new MacPro in January 2008. Since that time i've been waiting for Alsoft to release an updated version of DiskWarrior 4 to support my machine (in case something goes wrong -- nothing has though). It only took them 10 months to release the update. As of 10/27/08, it's supported in their new version 4.1.1.

Here's the catch, this new version (4.1.1) doesn't support the new MacBooks/MacBook Pro/MacBook Air models. I bet it's another 10 months before these idiots can update their software code. How are they going to make money selling old outdated software?

Bottom line: With this type of turnaround, i'm no longer purchasing their products, as they are unreliable!

[64stang06]

One reason they don't support the new models is the OS running on them. Until Apple releases 10.5.6, Alsoft won't be able to do anything to get those machines supported. It may/may not take 10 months, it depends on how testing goes before releasing it. And FWIW, I've had no issues and very good success with DiskWarrior when needed. They'll keep getting my money, no questions asked.

[Spheric Harlot]

Originally Posted by AppleGirl1990 

I purchased a new MacPro in January 2008. Since that time i've been waiting for Alsoft to release an updated version of DiskWarrior 4 to support my machine (in case something goes wrong -- nothing has though). It only took them 10 months to release the update. As of 10/27/08, it's supported in their new version 4.1.1.

Here's the catch, this new version (4.1.1) doesn't support the new MacBooks/MacBook Pro/MacBook Air models. I bet it's another 10 months before these idiots can update their software code. How are they going to make money selling old outdated software?

Bottom line: With this type of turnaround, i'm no longer purchasing their products, as they are unreliable!

I'm sorry, but these "idiots" are the ONLY ONES I know of that are bucking the trend by only releasing software when it's DONE.

And goddammit, if you're building file system repair tools, you're gonna make DAMN sure that the bastard is running properly before slapping a "supported" label on it.

In fact, what you criticize is PRECISELY what makes Alsoft DiskWarrior the #1 choice in troubleshooting software.

You are completely off-base here.

[turtle777]

Originally Posted by Spheric Harlot 

I'm sorry, but these "idiots" are the ONLY ONES I know of that are bucking the trend by only releasing software when it's DONE.

And goddammit, if you're building file system repair tools, you're gonna make DAMN sure that the bastard is running properly before slapping a "supported" label on it.

In fact, what you criticize is PRECISELY what makes Alsoft DiskWarrior the #1 choice in troubleshooting software.

You are completely off-base here.

I understand your argument, but it's flawed.

The *file system* did not change.

So what *exactly* are the challenging changes in the new MBPs that make the software update and testing such a long and tedious process ?

-t

[Chuckit]

DiskWarrior is fairly low-level software with potentially catastrophic results if something goes wrong. It's surprising what little changes can mess up even higher-level programs if you don't test them properly. I agree their long release cycle can be annoying, but I also agree that it's very responsible of them to place product quality first, even before profits. I think DiskWarrior is very good software.

If you always buy the latest hardware and replace it whenever something else comes out — anything else, whether it's aimed at the same market or not — yeah, maybe DiskWarrior isn't the best choice for you. But I'd think that's a fairly unusual pattern.

[Hal Itosis]

Originally Posted by AppleGirl1990 

Here's the catch, this new version (4.1.1) doesn't support the new MacBooks/MacBook Pro/MacBook Air models.

I think what you might have meant is that: the current DW version
doesn't support booting those hardware models from the DW CD.

That's not quite the same as "doesn't support". Booting from the CD is
just one way to utilize DW. I never do this, but rather prefer to slice my
HD into partitions, and have 2 bootable OSs available from which to run
DW on the other volumes at the drop of a hat. [or, boot from an ext. FW]

CD booting is painfully slow, and has other disadvantages compared
to HD booting. Also, I think Alsoft is at the mercy of Apple to some
degree, with respect to what technical details (and licensing grants)
they are privy to, when it comes to selling users a bootable Mac OS.

[turtle777]

Hal, that's a helpful distinction.

It would also confirm that the underlying "repair algorithm" should not need any adjustments, since the file system is the same.

-t

[AppleGirl1990]

Hal, you are correct. Software still works for some, but i run it by booting from a CD. So for me, it wouldn't work.

TurtleCakes, i think you understand where i'm coming from. To sum up, the only difference between version 4.1 and 4.1.1 is that it now can boot on the newer computers. This took 10 months. I'm not sure why this took 10 months to alter the boot code! That's my point.

I agree, software should work 100% before going GM. But 10 months for this type of fix? They need to get some new software programers.

[64stang06]

The only bad thing for me is that if I get a new MacBook, I can no longer use my FW drive with Disk Warrior to do repairs if needed.

[CharlesS]

Originally Posted by AppleGirl1990 

Hal, you are correct. Software still works for some, but i run it by booting from a CD. So for me, it wouldn't work.

TurtleCakes, i think you understand where i'm coming from. To sum up, the only difference between version 4.1 and 4.1.1 is that it now can boot on the newer computers. This took 10 months. I'm not sure why this took 10 months to alter the boot code! That's my point.

I agree, software should work 100% before going GM. But 10 months for this type of fix? They need to get some new software programers.

If you prefer to use software that is released in a half-assed fashion without doing proper testing first, you are free to try out their competition instead.

Just make sure you back up your hard drive first.

[besson3c]

Why not just boot off of your included OS X Software Restore DVD and run Disk Warrior from there? You just need to be able to boot off of different media, right? Many options here...

[Spheric Harlot]

Originally Posted by besson3c 

Why not just boot off of your included OS X Software Restore DVD and run Disk Warrior from there?

That's not exactly easy to do, you know.

[Chuckit]

Unless I'm having a very premature senior moment, the Software Restore DVDs don't give you access to anything except Installer and Disk Utility.

[turtle777]

Originally Posted by besson3c 

Why not just boot off of your included OS X Software Restore DVD and run Disk Warrior from there? You just need to be able to boot off of different media, right? Many options here...

Originally Posted by Chuckit 

Unless I'm having a very premature senior moment, the Software Restore DVDs don't give you access to anything except Installer and Disk Utility.

Yes, besson, please tell us how this works.

-t

[CharlesS]

My guess is that you'd put DiskWarrior on a USB flash drive, then boot from the DVD and go to the Terminal via the Utilities menu, then use the Terminal to launch DiskWarrior off of the USB flash drive. Not the most intuitive thing in the world, but it would probably work.

[besson3c]

I've never used the OS X Software Restore thing, but I figured that it was like the OS X installer that allows you to launch the Terminal? If so, from the Terminal you could launch Disk Warrior.

[CharlesS]

Ha, I called it!

[turtle777]

Originally Posted by besson3c 

I've never used the OS X Software Restore thing, but I figured that it was like the OS X installer that allows you to launch the Terminal? If so, from the Terminal you could launch Disk Warrior.

That's what you call Many options here... ?

-t

[besson3c]

No, turtle... Here are the other options:

1) Boot from a clone of your machine on an external drive

2) I was going to suggest Firewire Target Disk mode, but I guess there is no new equivalent to that. Bummer.

3) Remove the drive and attach it to another computer

4) Install a new copy of OS X onto external media, boot from there


You need to relax. There is no need to be confrontational about something this insignificant. I'm glad you are not my nurse!

[turtle777]

Originally Posted by besson3c 

No, turtle... Here are the other options:

1) Boot from a clone of your machine on an external drive

2) I was going to suggest Firewire Target Disk mode, but I guess there is no new equivalent to that. Bummer.

3) Remove the drive and attach it to another computer

4) Install a new copy of OS X onto external media, boot from there


You need to relax. There is no need to be confrontational about something this insignificant. I'm glad you are not my nurse!

Or, maybe saying Many options here, in conjunction with suggesting booting from OS X Software Restore DVD was a bit misleading ?

Don't worry, I still like you.

-t

[Hal Itosis]

Originally Posted by AppleGirl1990 

Hal, you are correct. Software still works for some, but i run it by booting from a CD. So for me, it wouldn't work. To sum up, the only difference between version 4.1 and 4.1.1 is that it now can boot on the newer computers. This took 10 months. I'm not sure why this took 10 months to alter the boot code! That's my point. I agree, software should work 100% before going GM. But 10 months for this type of fix? They need to get some new software programers.

As I suggested at the end of my post, the delay is probably due to the fact that
Alsoft may not get all necessary technical info the instant hardware updates ship.

Here is part of what Micromat says "About Bootable Systems":

The systems we provide are licensed from Apple. They are specially-designed, minimal systems that are optimized to run from non-write media like a CD or DVD. They do not contain all the features found in a full Mac OS installation, such as a Finder, Apple menu options, etc. Consequently, as Apple releases new Macintosh models, new system components are usually required to boot them. In that case, devices or media using earlier systems will not be able to boot the newer models. Micromat must wait until Apple releases new system versions (boot DDKs) in order to incorporate these official minimal systems in their products to be able to boot these newer Macs. This wait is often several months.

 
With respect to the other sub-topic, this may be of (minor) interest:
Must I boot from the TechTool Pro 4 CD to optimize?

[besson3c]

Originally Posted by turtle777 

Or, maybe saying [I]Many options here[/I,] in conjunction with suggesting booting from OS X Software Restore DVD was a bit misleading ?

Don't worry, I still like you.

-t

Yeah, I guess you're right.

It relieves me to know that you still like me. To be honest, for some reason even though I can't put my finger on it I've always liked you. I mean, *really* liked you. I think you're just a really cool guy, and seeing your turtles in your signature always make me smile. I know this sounds like I'm being sarcastic or silly, but I can't help it, I like you!

[turtle777]

Besson, I like you, too.

Even though you're full of sh!t poop

-t

[Veltliner]

Originally Posted by Chuckit 

DiskWarrior is fairly low-level software with potentially catastrophic results if something goes wrong. It's surprising what little changes can mess up even higher-level programs if you don't test them properly. I agree their long release cycle can be annoying, but I also agree that it's very responsible of them to place product quality first, even before profits. I think DiskWarrior is very good software.

If you always buy the latest hardware and replace it whenever something else comes out — anything else, whether it's aimed at the same market or not — yeah, maybe DiskWarrior isn't the best choice for you. But I'd think that's a fairly unusual pattern.

Why is it low-level?

Low-level never means anything good.

But, at the same time, you are giving the impression that it's pretty good.

So, what's low level about it, and what would be a higher level app?

[Veltliner]

Originally Posted by besson3c 

Yeah, I guess you're right.

It relieves me to know that you still like me. To be honest, for some reason even though I can't put my finger on it I've always liked you. I mean, *really* liked you. I think you're just a really cool guy, and seeing your turtles in your signature always make me smile. I know this sounds like I'm being sarcastic or silly, but I can't help it, I like you!

Sorry.

Didn't want to interrupt an emotional scene.

When's the marriage?

[goMac]

Originally Posted by Veltliner 

Why is it low-level?

Low-level never means anything good.

But, at the same time, you are giving the impression that it's pretty good.

So, what's low level about it, and what would be a higher level app?

Huh? It has to be low level because that's the only level at which you can alter the bits on a disk. A lot of stuff can ONLY be done low level. Graphics drivers are also low level, and no one gets upset...

There are no high level apps that do the same thing because this can't be done on a high level.

Besides, it doesn't even make sense. All high level code is is code that was written using low level code other people wrote. Any way you program you're going to end up with low level code in the end.

[Amorya]

Originally Posted by Veltliner 

Low-level never means anything good.

Wrong.

[Ted L. Nancy]

What is diskwarrior and why would I need it?

[Big Mac]

Originally Posted by Ted L. Nancy 

What is diskwarrior and why would I need it?

It's the best disk utility software on the platform.

[Hal Itosis]

Originally Posted by Ted L. Nancy 

What is diskwarrior and why would I need it?

Mainly because Apple's Disk Utility isn't able to fix every type of disk damage (directory tree/catalog).
The alternative to using a "superior" utility is to erase the problem volume and restore from backup.

What is DiskWarrior?

[even if nothing is wrong, occasionally "optimizing" the directory can also be beneficial: HFS+]

[CharlesS]

Originally Posted by Hal Itosis 

HFS+

The author of that page does not seem to understand what a B-tree is.

[iomatic]

I wonder if this will matter with SSDs.

[Ted L. Nancy]

Originally Posted by Hal Itosis 

Mainly because Apple's Disk Utility isn't able to fix every type of disk damage (directory tree/catalog).
The alternative to using a "superior" utility is to erase the problem volume and restore from backup.

What is DiskWarrior?

[even if nothing is wrong, occasionally "optimizing" the directory can also be beneficial: HFS+]

I had already read all that. Im still not certain if I would need this.

[CharlesS]

Well, the hardware will be more robust, but I suppose you'd still be susceptible to software-related problems, situations where the power goes out while the computer is writing something, etc. What I wish is that we would get a new file system (ZFS?), because HFS+ is quite a bit old and outdated.

One nice thing about SSDs is that since you don't have the slowdown anymore from the drive heads moving around on the platter, disk fragmentation will cease to be an issue at all. In fact, defragging a SSD is a very bad idea since it will rewrite most of the blocks on the disk and bring you closer to hitting the drive's write limit.

Originally Posted by Ted L. Nancy 

I had already read all that. Im still not certain if I would need this.

DiskWarrior isn't a tool that you use very often, but where it comes in handy is when something happens to your drive such that it is no longer bootable. In cases like this, DiskWarrior's ability to get your drive working again is quite phenomenal compared to the other tools available for OS X.

It's a bit like insurance, really. You hope that you won't have to use it, but once you do, you'll be glad you have it. I know that DW has definitely saved my ass a few times, and I'm glad to have it even though it's been a while since the last time I used it.

[Chuckit]

Originally Posted by Hal Itosis 

[even if nothing is wrong, occasionally "optimizing" the directory can also be beneficial: HFS+]

I'd take anything that guy says with a grain of salt. He seems to be on the wrong side of delusional sometimes.

[besson3c]

HFS+ is one of OS X's biggest weaknesses. Many have rightly sung praises for ZFS in consideration of its feature set, but ZFS is also still a relatively young file system. If you Google for ZFS failure stories you'll find a number of server admins who are not yet recommending it for production usage. It's hard to say how valid these opinions and experiences are, but in general it takes many years for a newish file system to be considered stable. ZFS may not be the default file system on Snow Leopard, but merely an option, it will be interesting to see how it is utilized (I haven't read anything official from Apple).

In the meantime, it sucks that we are stuck with HFS and occasionally having to rely on software like Disk Warrior to repair stuff, not to mention endure the poor performance of HFS.

[goMac]

HFS+ is not awful for joe six pack. For a power user? Yeah, it's not great.

[besson3c]

Originally Posted by goMac 

HFS+ is not awful for joe six pack. For a power user? Yeah, it's not great.

It depends on how you define "awful". It's the slowest and least efficient of any modern file system, to my knowledge. It's tolerable, but really out of place in an otherwise modern and slick OS, and the whole management of metadata and trying to play nicely with Windows is a complete mess. Littering files is not only a waste of inodes on non-HFS filesystems, but it can also pose as a security risk as it alters checksums.

Really, I think metadata is best handled at the file system level, maybe with some sort of central database (perhaps extending Spotlight) to deal with transferring files to and from non-HFS file systems. I say Apple ought to scrap all of the type and creator code legacy junk and just worry about making metadata work well on Macs. Whether this means a central database, xattr, or something that ZFS offers, I don't know, but just about anything would be better than what we have now and all of the __MACOSX folders, .DS_store, .AppleDouble, trusting of file extensions, etc. hodge podge.

[CharlesS]

Originally Posted by besson3c 

Really, I think metadata is best handled at the file system level, maybe with some sort of central database (perhaps extending Spotlight) to deal with transferring files to and from non-HFS file systems. I say Apple ought to scrap all of the type and creator code legacy junk and just worry about making metadata work well on Macs. Whether this means a central database, xattr, or something that ZFS offers, I don't know, but just about anything would be better than what we have now and all of the __MACOSX folders, .DS_store, .AppleDouble, trusting of file extensions, etc. hodge podge.

THe __MACOSX folders only appear inside Zip archives, about which not much can be done no matter what they do to the file system. The .AppleDouble files are used on file systems over which Apple has no control, so I'm not sure exactly how they should solve that other than jettisoning the metadata entirely (The .DS_Store files could easily be replaced with an extended attribute on the folder, I'll admit).

[besson3c]

Originally Posted by CharlesS 

THe __MACOSX folders only appear inside Zip archives, about which not much can be done no matter what they do to the file system. All the rest of those except for .DS_Store are used on file systems over which Apple has no control, so I'm not sure exactly how they should solve that, frankly (The .DS_Store files could easily be replaced with an extended attribute on the folder, I'll admit).

How about some sort of metadata record for the zip file itself with some sort of unique ID, and then separate records for each individual file inside the zip archive relating to the ID of the parent zip file? It seems like Spotlight is sort of taking on cradle to grave monitoring of files, so why can't it be extended to include zip file contents?

As for .AppleDouble, .AppleSingle, etc. I agree that Apple has no control over these implementations, but they are only possible because of Apple's one time dependence on dual forked files. If they officially scrap all of this nonsense, these directories can be scrapped.

As it stands, I imagine that basically each file write effectively costs three file writes: one for each fork, and one for a Spotlight entry, as necessary. I don't see why they couldn't change this so that the file is written once, and written to Spotlight at some point while the system is idling reading from the block level ZFS logs which would also be used for Time Machine back-peddling? Is this possible?

[CharlesS]

Originally Posted by besson3c 

How about some sort of metadata record for the zip file itself with some sort of unique ID, and then separate records for each individual file inside the zip archive relating to the ID of the parent zip file? It seems like Spotlight is sort of taking on cradle to grave monitoring of files, so why can't it be extended to include zip file contents?

Because the purpose of the zip files is to make a flat archive that can be sent over e-mail or any other medium without trashing the metadata. If the archive itself has metadata that can be trashed, it sort of defeats the purpose.

As for .AppleDouble, .AppleSingle, etc. I agree that Apple has no control over these implementations, but they are only possible because of Apple's one time dependence on dual forked files. If they officially scrap all of this nonsense, these directories can be scrapped.

If you moved extensible metadata to xattr or something else, you'd still need some sort of dotfile to preserve that metadata when you moved the file to another file system. It's not anything inherent to dual-forked files. I don't see an easy way around that problem.

[besson3c]

Originally Posted by CharlesS 

Because the purpose of the zip files is to make a flat archive that can be sent over e-mail or any other medium without trashing the metadata. If the archive itself has metadata that can be trashed, it sort of defeats the purpose.

Ahh, I see what you mean.

If you moved extensible metadata to xattr or something else, you'd still need some sort of dotfile to preserve that metadata when you moved the file to another file system. It's not anything inherent to dual-forked files. I don't see an easy way around that problem.

My thinking is xattr or nothing. There needs to be some sort of open standard for this purpose, xattr fits this bill nicely. I don't think we should coddle Windows, and Windows users are probably just going to discard those dot files anyway.

[Chuckit]

Originally Posted by besson3c 

Ahh, I see what you mean.




My thinking is xattr or nothing. There needs to be some sort of open standard for this purpose, xattr fits this bill nicely. I don't think we should coddle Windows, and Windows users are probably just going to discard those dot files anyway.

The Internet doesn't support xattrs.

[Hal Itosis]

Originally Posted by CharlesS 

The author of that page does not seem to understand what a B-tree is.

...and the why is because...

[CharlesS]

Originally Posted by besson3c 

My thinking is xattr or nothing. There needs to be some sort of open standard for this purpose, xattr fits this bill nicely. I don't think we should coddle Windows, and Windows users are probably just going to discard those dot files anyway.

But it's not necessarily a Windows machine that's involved every time a dotfile happens... in fact, I'd wager that it's probably more common for dotfiles to end up on Mac users' USB flash drives which are almost always preformatted using FAT32. Trashing metadata in this case is a Bad Thing™, and unfortunately if a random FAT32 disk is attached, there's no real way to know whether it's owned by a Mac user who'd want to keep the metadata or a Windows user who might trash it.

[Hal Itosis]

Originally Posted by Ted L. Nancy 

I had already read all that. Im still not certain if I would need this.

If you "had already read all that" then... why did you ask what is DiskWarrior?
If you "had already read all that" and still don't know what DiskWarrior "is"...
then i can't help you.

[PS: there are over a dozen links on that DW page answering many related questions. Read them too?]

[CharlesS]

Originally Posted by Hal Itosis 

...and the why is because...

Well, let's see...

Originally Posted by Rixstep

In order to work, the HFS binary tree has to be pre-sorted in a benign way. The top root node of the tree must always point to the middle of the tree, seen from the sorting algorithm used.

If a new file is introduced, so that the current root of the tree is no longer in the middle of the sort, the entire tree must be reorganised.

Every binary tree node has children which reach all the way down to the actual file data. The middle value becomes the root of the tree. Whenever a new file is added to a directory, the entire directory tree must be rewritten, to ensure that the root is in the middle.

This must be done every time a directory is 'edited': every time a file name changes, every time a file is added, every time a file is deleted.

When files are moved from one directory to another, both binary trees for both affected directories must be rewritten.

To alleviate a little of the pain, Apple engineers invented a new sort of binary tree which they call the B*-tree. This is a curious animal to say the least: although the name 'binary' implies 'two', the Apple B*-tree has not two, but three nodes.

Even more incomprehensible, the new third node is never used [sic]. This new node has a value, but the tree is constructed in such as way that no node ever uses it. All searches through the tree must have keys which always sort higher [sic].

Only the nodes at the very bottom of the tree, the so-called leaf nodes, have any file information. All the rest of the nodes merely point onward (downward) ultimately to these leaf nodes.

1. He seems to think that HFS uses a binary tree to store its directory contents (or that it would somehow make sense to do so).

2. He doesn't seem to know the difference between a binary tree and a B-tree.

3. He seems to think that every addition of a single leaf node to a B-tree would cause the entire tree to need to be reorganized.

4. He seems to think it's odd for a node in a B-tree to have more than two children (WTF?).

5. He seems to think that a B*-tree is a relatively new concept invented by Apple (Knuth's The Art of Computer Programming, Volume 3 mentions B*-trees, and it was written in 1973, before Apple was even incorporated and over a decade before HFS was introduced).

6. He seems to think that nodes in Apple's B*-tree have only three children, when the documentation states that they can have from 1 to 15, whereas the HFS+ documentation simply says that an index node can have two or more children. Probably he just looked at the pictures.

Just based on that section of the page, I'm not instilled with a great confidence that he really understands the topic he's discussing. To me it looks as though he had some vague idea of what a binary tree is, saw the term "B-tree" come up with regard to file systems, and assumed the "B" stood for "binary".

[Hal Itosis]

Thanks much!

[AppleGirl1990]

Apple should include a better repair utility program on it's startup disk. Why do we even need 3rd party software? Apple made it, Apple should be the best suited to fix it.

Do you agree with that?

[turtle777]

Originally Posted by AppleGirl1990 

Apple should include a better repair utility program on it's startup disk. Why do we even need 3rd party software? Apple made it, Apple should be the best suited to fix it.

To you agree with that?

I'm not sure if I agree with that. If Apple developed and supported all kinds of special programs for *all* possible scenarios that could go wrong, OS X would be much more expensive. Let alone, the quality of those apps would never be as good as third party's, who make a living off of developing good software solutions.

Really, your suggestion doesn't work.

-t