Does Disk Utility Lie?

[awrc]

The reason I ask is that, since I've had some issues with software crashing (which presumably leaves open files) including the Finder, and with my Big Disk Extreme being cranky when used in Firewire 800 mode, more than once I've gone into Disk Utility and run "Verify Disk" on the drive. Disk Utility assures me that the volume is fine.

However, if I then pop open a terminal window and sudo the following:

fsck_hfs -p -f -r /dev/rdisk2s3

The -p -f combination is apparently what's required to force it to do a thorough check on a journaled volume, the -r tells it to rebuild the catalog while it's about it. The device just happens to be the volume where the software that crashes most often keeps its files.

This almost always finds problems. Wrong file counts, wrong directory counts, wrong free block counts, and a problem with the volume header.

Is it actually the case that Disk Utility is missing genuine errors, or is it just the case that the "fsck with serious prejudice" way I call fsck_hfs finds cases that are technically errors but that would get repaired periodically, presumably by a preen being run by one of the cron jobs, and that don't really have any effect?

Al

 

[Eniregnat]

This is a really intersecting question. I recently had a failing drive I used every repair program, utility, script, and command line level form of diagnostic repair that I could.

Both Norton and TechTools found errors on drives, and they said that they fixed them, and on reboot and reaccess of the drive, they would find the same errors.

DiskUtility didn't report anything wrong other than wrong permissions that never seemed to be permanently fixed. Though I would say that DiskUtility did the least amount of damage to the existing file structure.

MacSweeper, Onyx, and the Cleaning Actions, are basically scripts that access the command line. Onyx and MacSweeper are brilliant examples of Apple Script. Running them repaired permissions, etc..., and returned no error messages, except as log entries.

Terminal commands yielded the same results, with verbose response always noting errors, that were repaired.

The funny thing is that I don't think that running these programs really improved stability or performance, other than running my standard monthly repair scripts.

I don't think that DiskUtility lies, rather it may be one of two cases. 1- the errors are not enough to even be noted or repaired, much like the error correction routines with memory usage and drive data. 2- The errors are not even looked for by DiskUtility.

Among my less computer literate Mac user friends, those that don't run every disk utility, script etc.. I don't really see to many problems.

Semi-off topic: After it all is said and done, all I can firmly say is that once a drive starts noting SMART errors, there is no way to clean the drives diagnostic memory to see if the errors were part of a short period of aborations or really something drastic. Since all of my problems have been solved by installing a new drive, and upgrading to Tiger, I would guess that the SMART report was true, and as it degraded from Failing- Back up data, to Failed- Copy any data that you can, it was likely very damaged.

[Edit] Oh, to answer the question in short- No.