I just received my copy of DW 4 and installed it. This version has a feature not found in DW 3, namely the ability to check files and folders. I tried it and got the following report:

DiskWarrior scanned the disk named "Tiger HD" checking all files and folders for damage and potential compatibility
problems.



Disk: "Tiger HD"

The Property List data was checked in 2,539 files.

The Resource Data was checked in 8,839 files.

The maximum Folder Depth on this disk is 17. This does not exceed the maximum recommended depth.

Location: "Desktop"



File: "extras.rsrc"

Detected that the resource header is damaged and cannot be repaired

Location: "Tiger HD/Users/jonathanmchuzi/Desktop/software/Mactracker.app/Contents/Resources/"



File: "extras.rsrc"

Detected that the resource header is damaged and cannot be repaired

Location: "Tiger HD/Applications/Mactracker.app/Contents/Resources/"



Explanations:



Folder Depth: This number indicates how many folders are nested inside each other. If a disk contains only three
folders and Folder A is inside Folder B and Folder B is inside Folder C, then this disk has a maximum folder depth of
three. Folders nested too deeply can cause software compatibility problems.



Property List: This is a standard file format for storing data and is often used to store preferences. The names of
these files normally end with a .plist file extension. Corrupt property list files can cause system instability.



Resource Data: This is an older file format for storing data and was often used to store preferences. The names of
these files normally end with a .rsrc file extension. Corrupt resource data files can cause system instability.



Time: 12/22/06 5:53:50 PM

DiskWarrior Version: 4.0 - RN529815

I have been using MacTracker (and I have the latest version) for quite some time without any hint of trouble. Do the above error messages merit any action or should I ignore them?

Jon, "the resource header is damaged" is insufficient to know whether it is serious or trivial, but the fact that the app works without problem strongly suggests that it is trivial and can be ignored. The fact that your cloning app has not protested (or you would have said so) would add weight to suggesting that you can ignore what DW has found. If the matter bothers you you might try d/loading a fresh copy of the app. If you want to know more the person to ask is the author of 'MacTracker'.

Of possibly more interest is why you have two copies of the app - not generally advisable - but I know nothing about that app and you may have a good reason. If by chance the two copies are different versions then I wouldn't bother to either re-d/load or ask - I would most definitely forget the whole thing.

Thanks for your reply, Andreas. I forgot that I had stored a copy of a previous version of MacTracker in a Software folder that I created on the desktop. I trashed that one (which, by the way, was an older version) and we'll see what happens. I'm a tad busy now so I don't have time to re-run DW's file check but I'll try it again and post back with the results.

I tend to keep backup copies of software to avoid having to re-download if I need to reinstall. The current copy in my Software folder is a .dmg file, not the actual app. That shouldn't cause any problems. The one that I trashed was the actual app. I won't bore you with the stupid reasons why I kept a second copy.

Happy Holidays to you and your family!

OK, here's the update. After trashing the extra copy of MT, DW's file check reported the same problem with the copy located in Applications. At the risk of being repetitiously redundant, the report is as follows:

DiskWarrior scanned the disk named "Tiger HD" checking all files and folders for damage and potential compatibility
problems.



Disk: "Tiger HD"

The Property List data was checked in 2,539 files.

The Resource Data was checked in 8,817 files.

The maximum Folder Depth on this disk is 17. This does not exceed the maximum recommended depth.

Location: "Desktop"



File: "extras.rsrc"

Detected that the resource header is damaged and cannot be repaired

Location: "Tiger HD/Applications/Mactracker.app/Contents/Resources/"



Explanations:



Folder Depth: This number indicates how many folders are nested inside each other. If a disk contains only three
folders and Folder A is inside Folder B and Folder B is inside Folder C, then this disk has a maximum folder depth of
three. Folders nested too deeply can cause software compatibility problems.



Property List: This is a standard file format for storing data and is often used to store preferences. The names of
these files normally end with a .plist file extension. Corrupt property list files can cause system instability.



Resource Data: This is an older file format for storing data and was often used to store preferences. The names of
these files normally end with a .rsrc file extension. Corrupt resource data files can cause system instability.



Time: 12/23/06 11:03:16 AM

DiskWarrior Version: 4.0 - RN529815

Since I am not having any issues at all, I am going under the assumption that this is trivial. I will contact Alsoft to see if they have an opinion.

BTW, you were correct in your assumption about cloning. I have cloned with Carbon Copy Cloner and Super Duper; neither one had any hiccups in the cloning process.

    "I will contact Alsoft"

I think that's a bit unfair on poor Alsoft ( ). If you want to contact anyone surely it should be the author of MT.

The format of preference or .plist files is not rigidly fixed. My suspicion, as you report that MT works perfectly and that CCC has no problem copying the file, is that MT is perhaps using a slightly idiosyncratic format which DW has trouble interpreting. All apps that check prefs files, e.g. "Preferential Treatment", are subject to that potential difficulty.

Excellent idea, Andreas. I will contact MT's developer for his opinion.

As an addendum, TechTool Pro 4.5.1's file checks came up clean. Of course, TTP may be doing something different. By the way, although DW 4 checks preference files, I don't know if it does anything other than run plutil. As you correctly said, Preferential Treatment (which just puts a GUI on plutil) can have difficulties.

I received a very quick response from Ian Page, the developer of Mactracker. It is:

Hi Jonathan,

The file in question is not a traditional resource file though it has the
.rsrc file extension which is likely why DW is taking issue with it. If
Mactracker is working fine, I wouldn't worry about it.

Happy Holidays!
--
Ian Page

I'll take Ian at his word and assume that all is well.

Almost word for word what Andreas said – so the Developer must be right!       

Back in the Middle Ages I sometimes created a 'pref file' for apps I wrote. They didn't have to be in any particular format and I just did what was convenient/logical/easy in any situation. Sometimes the prefs would be stored in resources in the app's resource fork (equivalent to resource items in an app's bundle nowadays), sometimes 'properties' within the code, sometimes a separate data file, whatever. If I had used an extension of .rsrc or .plist (but we didn't tend to back then) DiskWarrior, Preferential Treatment and similar apps would now cast aspersions on my work. I would in turn tell them to mind their own business!

I hope you can now see clearly that you can forget this whole matter. Nothing is "wrong".

In reply to:

---

Almost word for word what Andreas said – so the Developer must be right!

---

Ah yes, Andreas, I have always admired you for your humility. It's your only character flaw.

Once again, Happy Holidays!

> Nothing is "wrong".


In my usual style, I would like to offer a slight contradiction:

1) As the developer admitted, he put a .rsrc extension on a file
that is not a traditional "resource" type structure. Okay, WHY?
That will only confuse programs that expect a file's contents to
be appropriate to the appended extension. Would you put a .txt
extension on a jpeg? That .rsrc extension on the Mactracker file
serves no positive purpose. Of course, the developer will say...
"That file is inside my bundle, and no one has any business going
in there". But, that's not a good *reason* to misuse the convention.

2) This second point may not be so much about 'wrongness',
but I'm not sure I like the idea of DiskWarrior delving into the
"file" arena. I just hope this indicates that its directory repair
functions are perfected to such an extent that the engineers
have plenty of free time to add new features. I trust that ver.4
doesn't crash due to the QuickTime issue (which was never
patched for version 3 users?). Plus, whatever happened to
Alsoft's disk defragger? That croaked around System 7 or 8,
and was to be updated... but it never resurrected. <sigh>

Anyway, Season's Humbug.

In reply to:

---

I trust that ver.4 doesn't crash due to the QuickTime issue (which was never patched for version 3 users?.

---

That appears to be the case. I rebuilt the directory on both my drives and had no issues whatsoever. If anything, DW 4 seems to work even faster than DW 3.

Contrary to your sage advice, I also contacted Alsoft about this issue. The reply:

Hi Jonathan--

I downloaded the current version of MacTracker and receive the same
message in the DiskWarrior FileTest.

We looked at the file "extras.rsrc" and it does not meet the criteria as
an actual .rsrc file. There is no header data.

However, this doesn't mean that the MacTracker application itself isn't
aware of this and functions just fine with the file in this format. They
may have tacked the .rsrc suffix on for some reason unbeknownst to us.
However, the suffix alone does not make a proper .rsrc file.

Ultimately, you can simply ignore the message in DiskWarrior - we're
reporting it properly, but it obviously doesn't seem to have an effect on
the functionality of the MacTracker database itself.

-- Marc

So, I feel quite comfortable ignoring DW's error message.

Happy New Year!

As that sage wrote: "I hope you can now see clearly that you can forget this whole matter".   

FWIW my prognosis now is that the developer of MacTracker is fed up with hearing about this and will in his next release be using a different format for his prefs file. Whether or not that prognosis proves correct the advice remains as quoted!   

I may have a similar issue with some .bin files from a statistical program Instat3 (GraphPad Software). Tech Tool Pro 4.5 reported all files to be fine but DW 4 said that three files were damaged and could not be repaired. May be the same issue because the program works fine.
On another note, there is another interesting glitch in file identification with DW 4. When you have a comparison of old and new directories in DW on PPC (2.3 GHz DP G5, 1 GB RAM, OS 10.4.8), the program correctly identifies Word 2004 files with a .doc suffix as Microsoft Word files. However, the Excel files with .xls suffix are identified as Unix executable files and their icons are shown as black rectangles. Did not have PowerPoint files at root level so cannot tell. Upon rebuilt, the Excel files show properly so it is probably not dramatic. Overall, Hal may be right that DW file checking is not perfect.
Alex
2 GHz MacBook Pro, 1 GB RAM, OS 10.4.8, Office 11.3.2