imac 2009 OS 10.5.8
Just ran D/W and it says "Detected that the resource header is damaged and cannot be repaired"
It lists a long path which mostly dwells on PSE 10 (editor & organizer)
Yesterday I used PSE 10 for a couple of hours without incidence.
Should I be concerned? I'm going to run TTP6 and edrive and see what that tells me, if anything.
Can someone enlighten me about the resource header?
jaybass

DW will check fork structures. This error is data corruption, not directory or hardware problems. (not directly, it could have been CAUSED by directory or hardware problems)

The file may or may not be usable.

What's the exact file in that long path?

After posting, I ran TTP6. using edrive, it checked 'Rebuild and repair vloumes directory' It reported "No rebuild errors Encountered" Then it checked "Run Volume Optimization" It defraged and erased free free space. When I used D/W,
I also checked the files and they are ok.
Using the HD volume, TTP6 did a complete computer check and it was also ok.
You say the file may or may not be usable. How do I find that file?
Thanks for your response.

jaybass

Path Verbatim. "imacHD/app/PSE10/PSE10 organizer.app/contents/elements autoanalyizer.app/contents/frameworks/adobe owl.frammwork/version/A/resources/adobeSWFL.bundle/contents/resources/

Some of the above letters should be upper case. Unfortunately, I didn't save the report hence having to type it. Does that help?

jaybass

may affect elements 10 app (reinstall it) but nothing beyond that.

I have just tried to open OSE 10 and a window opened saying " A required application library failed to load and the product cannot continue. Please reinstall the application"
I will reinstall and see what happens.
jaybass

I reinstalled PSE 10 and it is working fine. I again ran D/W and the resource header wasn't mentioned so that problem file doesn't exist now.

Thank you both for helping me out.

jaybass

...but it might come back.

Lesson learned: don't bother running DiskWarrior's 'check files' routine.
[or at least: don't accept those results as gospel by allowing it to repair them.]

Some programs put strange stuff into files whose names have a .plist extension.
Some programs put strange stuff into files whose names have a .rsrc extension.

While that may be bad practice on the part of such programs, PSE wasn't giving you any problem until DW "fixed" it.

Alsoft probably added that feature just to ward off the 'one trick pony' label on DW.
And this isn't the first time i've heard of things going wrong with it.

I don't think DW repaired anything there; in fact Jaybass mentioned in his OP that DW couldn't repair it. A subsequent run with TTP might have, but that isn't clear from its description. One conclusion could be that the mere running of this particular DW routine had something to do with (if not caused) its findings.

Care to elaborate?

Not particularly. (I didn't feel like reading every word -- the flagged file was fine, so DW was wrong).

Just take what's useful from my previous post, and discard what you don't need.

> Lesson learned: don't bother running DiskWarrior's 'check files' routine.
[or at least: don't accept those results as gospel by allowing it to repair them.]

> PSE wasn't giving you any problem until DW "fixed" it.

DW flags files it thinks are problematic (xml-wise, I believe); it doesn't have repair functionality...can't fix anything.


> Alsoft probably added that feature just to ward off the 'one trick pony' label on DW.
And this isn't the first time i've heard of things going wrong with it.

You're guess about the feature addition rings true (although if that and repairing permissions are the best they can do they're pretty short on imagination), but can running a simple file-parsing routine actually result in damage to a parsed file? Can you cite any examples?

"but it might come back" Are you aware of any particular reason?
If there are conditions under which this problem might re-occur, please enlighten me.
jaybass

Well, that certainly explains why I get the same results every time I run the file structure test on DW and why I'll now stop wondering "Gee, why doesn't it ever fix these?"

Interesting bit.....I just ran the same test on both DiskWarrior and TechTool Pro. Not only are the two results very different, there isn't a single file common to both. DW had the most ominous messages.


DiskWarrior - Identified 5 Files

3 said - File: "Localized.rsrc"! Detected that the resource header is damaged and cannot be repaired

2 said - File: "com.apple.iphotomosaic.plist"! Detected that Property List data is damaged and cannot be repaired.

TechTool Pro - Identified 10 Files

8 said - File is corrupt or is an unsupported file format (6 were .jpg, 2 were .png)

2 said - The end of the file was reached: (Both were .gif)


Okay, well maybe it's not that interesting....but it's at least curious.

> "Gee, why doesn't it ever fix these?"

The important thing to remember is that they don't necessarily need to be fixed.


Just because a utility says that it has detected (I'll call it) non-standard xml code in a file doesn't mean that the file is damaged.

Clink....which is the sound of the penny dropping. Thank-you to both you and Hal.

There's no way for any utility program to fix a damaged plist or resource file because there's no way for the computer to know what information is supposed to be there.

Let's take a property list (plist) file as an example. These files are often used to store preferences for a program. They're just text files, and they have special keywords that look a little bit like HTML. The reason they are stored this way is that OS X contains a programming API to read a plist text file and hand the program back all the information it needs, so it's an easy way for a programmer to save information.

A simple plist file might look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<string>Bill</string>
<string>HGQN-WCCF-WORF-QAHZ</string>
<true/>
</plist>

This might be a simple property list to store information that says a shareware program has been registered (with the <true />), that the program is registered to Bill, and that the serial number is HGQN-WCCF-WORF-QAHZ.

But let's say that the file is damaged. Let's say that it got overwritten by a letter to Bill's mom, because the disk directory was screwed up and the letter was saved to the same spot on the disk that the plist file was saved to. Now it looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<string>Bill</string>
<string>HGQN-WCCDear mom,

I really liked the sweater you knitted me for Christmas. As you know, purple and Day-Glo orange are my favorite colors, and they look so good together! Especially with the lime green stripes you added as an accent! I can't wait to wear it to work. The judge and the other lawyers will love it.

Love, Bill

Now, DiskWarrior can tell that the file is damaged, because plist files have to follow certain rules: they always have to have the same number of closing and opening tags, and they always have to end with </plist>. So DiskWarrior will report that this file is messed up. But it won't fix it, because it has no way to know what's supposed to go there.

The same is true of resource files. These can contain all sorts of information. It is common for programs to have several localized.rsrc files inside them. These are language files. When you run a program on OS X, the operating system will see what the language is set to on that computer, then it will search for a localized.rsrc file that has the same language. So if the programmer has made English and German versions of the program, the program will take all of its text (button labels, menu commands, and so on) from the English localized.rsrc file if the program is running on an English version of OS X, and will take them from the German localized.rsrc file if you run the program on a German copy of OS X.

If a program has a bad localized.rsrc file but still runs just fine anyway, that means that the damaged file is for a language you're not using. If you copied the program onto a different computer that was installed with a different language, it wouldn't run.

Again, a utility like DiskWarrior can't fix a localized.rsrc file, because it has no way to know what should be there; it can't tell what the buttons and menu items and so forth should say.

Despite the similarities in his opening sentence and our fourth sentence in the TechTool Pro manual section linked below, Tacit did not write our manual. We will fix our typos:

File Structures Test in TechTool Pro 5 & 6

First, thanks very much for taking time for a comprehensive response. After reading it, I did another experiment.

I tracked one of the .jpg files shown as "File is corrupt or is an unsupported file format:" It was an attachment to an old sent email message. I went to the message and the jpeg opened.

I then went back to the problem .jpg file and moved it to trash. I also determined, by trying to open it, that it was empty. I did a restart.

Thinking the file might re-build the way plists do, I went back to the folder that previously had the .jpg file but the folder was empty. I then returned to the email message containing the attachment and, although the file containing the description was no longer in the folder, the email jpeg opened.

So, long story short, it appears that I can get rid of these "File is corrupt or is an unsupported file format:" files without a lot of concern. I assume it will be the same with .png or .rsrc

I also re-ran the TechTool file structure test and, predictably, it found nine corrupt files (the ten from yesterday minus the one I trashed).

By the way.....that was some sweater. I had to put my sunglasses on just to read the description.

Thanks. I had read this but probably a bit too quickly. If I had perused a bit more carefully, I would have realized I shouldn't expect to see any .rsrc files.

You are welcome.

All of our manuals are now available online:

MicroMat Product Manuals

Aren't rsrc files included under " Check Databases (e.g. plist and xml files)?"

> So, long story short, it appears that I can get rid of these "File is corrupt or is an unsupported file format:" files without a lot of concern. I assume it will be the same with .png or .rsrc

With an image file, such as a png, I believe you're correct (other than that you'll lose the [Edit: source] image, but I believe that trashing plist and rsrc files will (Edit: possibly, if not) likely buy you trouble (Edit: because, as per Hal, the files may be flagged for being merely non-standard, rather than problematic).

Apparently not. TechTool has three options, including that one. It was selected (per the defaults).


....which raises the logical question: If both DW and TT only identify the files; the identified files may only be non-standard, not actually problematic; and, even if the files were a problem, neither program fixes them; why bother?

I believe rsrc files are included under the xml umbrella.

Anybody?

> ....which raises the logical question: If both DW and TT only identify the files; the identified files may only be non-standard, not actually problematic; and, even if the files were a problem, neither program fixes them; why bother?

The functionality is provided just to give you a heads-up on what may be an issue; there's really no need to even run the test unless you're troubleshooting a problem.

Why would they be? There is no overlap in their formats. xml is a pure text representation; a rsrc file is anything but. rsrc files date back to the Lisa (1983); xml was first described in 1997 and adopted by w3c in 1998.

rsrc files are in the sort of arcane ad hoc binary format that the xml founders were rebelling against.

The only reason the comment says "e.g. plist and xml files", calling out plist in addition to xml, is that xml is only one of the four formats that can be used for plist files. (The other three formats are NEXTSTEP (deprecated), bplist, and JSON (new with Lion).) They want to make it clear that plist files in the bplist format (at least) will also be checked.

Not that it would be hard to check a rsrc file. The RezDet tool will do all the heavy lifting for you.

> Why would they be?

I've got absolutely no idea; I was reacting to an earlier post that conveyed the impression suggested to me that they were.

Thanks for the clarification.