SanityCheck FAQ

SanityCheck can fix your structure file (ie, it can modify the data in your structure file in such a way that fixes the structure file when it is damaged).

Specifically, here are some of the things it will fix today:

* Object (any object) is outside of the bounds of the file.
* Method Data doesn't exist (even though method name does)
* Missing field data list in a table.
* Missing table method data.
* Subtable doesn't link to proper parent
* Layout data doesn't exist for a layout
* Bad form template counts
* Bad form template name
* Missing form template data.
* Missing form object method data.
* Poorly formed List
* Bad list count
* Bad List name
* Bad balloon help name
* Bad balloon help data (doesn't exist)
* Bad link to method data
* Some kinds of damage to the password table
* Bad picture names
* Missing picture data
* Bad count of pictures
* Orphan removal (non-referenced objects)
* Password table removal.

We have a large collection of damaged structure files. In the vast majority of cases the problem is that when damage occurs, it usually results in objects that are unrecoverable. Why? Because it is data-overwrite.

And, here's the important part: It's never a small data over-write. Never does one byte get corrupted. Usually whole areas of data are damaged.

[The cause of the data-overwrite is how disks work or how 4D's disk cache works. It's either going to be minimum 64 bytes (if 4D's disk cache writesincorrectly) or minimum 512 bytes (if the file system itself is doing something naughty). And that's the minimum size tobe damaged. Usually, when something gets damaged, it's notjust one "chunk" it's several 64 byte chunks or 512 byte chunks. So it's easy to see how the damage is usually catastrophic to one or more objects. There's simply no magical wayto fix the contents of the damaged forms or methods; it's now justrandom data.]

So the objects get damaged beyond repair. And 4D cannot read these objects (they are garbage after all) and may trip trying to access them.

Usually, the only way to fix is to delete the offending object AND the links in 4D to that object. (Remember, in a 4D structure file there lots of interrelations, so it's usually not just deleting an object, but chasing back up the reference list and removing the references.) This is one of the repair tools the SanityCheck gives you.

SanityCheck v4.5 and later flags this situation.

Most likely, the object has been tagged to be encrypted by 4D.

Since 4D introduced components, 4D has had the capability of encrypting objects in a structure file.

Those objects are only supposed to be encrypted if they are part of a component and if they are marked as Private.

However, very rarely, 4D has marked an object to be encrypted, even though it is not a part of a component at all, or if it's in a component, when it's not marked Private.

These objects are then encrypted, and SanityCheck cannot read them.

To check: use SanityCheck, open up the Browser (Cmd-B), on the left-hand list select "FI4D", then look for the name of the table. Double click to open it. What do you see? Even better: Take a screen shot and send it to support@committedsoftware.com.

It should not be encrypted (there are no components in this structure -- no MO4D object).

Try this:

* run 4D Tools: Compact on the structure. Does that fix it? Make sure you use a modern version of 4D Tools (at least 6.7.4, preferably 6.8.3). If it's not a 6.8 structure, for kicks, make a copy and upgrade to 6.8.3 and run 4D Tools:Compact 6.8.3 on it. You're just trying to get it to unencrypt
it. This probably won't work, because it would be too easy of a way to hack the protection in 4D...

* If that doesn't work, send the structure to 4D, Inc and ask them to help you remove the encryption.

Very early versions of 4D Tools had a bug where it incorrectly encrypted objects during compact (I believe it was 6.7.0). If this happened with recent software (say, after 6.7.4), then I should imagine that 4D, Inc would like to know how it happened.

Please note that this object is not "corrupted"-- it's just encrypted. 4D, 4D Tools, and 4D Insider should work OK with it. It's just 3rd Party tools like DataCheck and SanityCheck that will flag this as an error.

Installation of CarbonLib 1.6 is required for SanityCheck to work with v8.6 of the MacOS.

The sequence numbers exist only in the data file, not in the structure file. Therefore, to fix this type of problem, you need DataCheck.

With DataCheck you can use the "Table Information" from the "Special" menu to access information such as the Sequence Number.

You can then modify the sequence number to be whatever you desire.

The problem cannot be detected in the structure file by SanityCheck because
SanityCheck only works on structure files.

Full Question:
After running Sanity Check on my Windows 2000 based structure (v6.7.2) I have a large list of [209] errors indicating duplicate tags in the Resource file. The suggested fix is a bit cryptic. I do not have access to Macs. Could you please give me more insight to the seriousness of this problem, and a more detailed set of steps to follow in order to repair the Resource file.

Answer:
On the macintosh, there are two "forks" possible in each file on disk. One is the data fork (which is what we would all call the file in the Win32 world). The other is the resource fork. The resource fork could be considered a little data base, in that the data in the resource fork is ordered. There are types of data (PICT, TEXT, etc), and each type of data has many records. Each record has a record ID (which needs to be unique).

Under windows, 4D uses the .RSR file to store the resource fork from the macintosh.

What's going on with the [209] is that it finds that two records, in the resource fork, have the same ID, and that should never occur (in the normal state of the world).

The problem may or may not be serious. The duplicate IDs existing does not necessarily mean that something will go wrong as you use the file. 4D, when it reads the resources, will just "pick" one of the two of the duplicates.

However the question must be asked how this file got this way. And that's where the seriousness of the item comes into question. A very common way a file will have a [209] is due to damage in the file.

What may be the case is the one file has duplicate resources, you can re-install that .RSR file.

If not, you will have to edit the .RSR file using MacOS platform.

If the damaged resource fork is on a 4D file, you may see these lines when running SanityCheck:

Fatal Error: Resource 'vers:0x2A08' has duplicate ID. [209]
Fatal Error: Resource 'vers:0x2A1C' has duplicate ID. [209]
Fatal Error: Resource 'vers:0x2A31' has duplicate ID. [209]
Fatal Error: Resource 'vers:0x2A4E' has duplicate ID. [209]

This you should clean up using a MacOS machine with Resourcerer (or ResEdit). You fix it by deleting the duplicates in specified file, using the tool of your choice.

If you want to replace the entire .RSR file, open the current file with ResEdit, delete everything, and copy in the resources from the old file. This is, of course, if the old file is relatively recent and you've not done anything to modify the resources since the last backup.

If you are getting a lot of items like this:

Mac4DX Files: Resource File ':Mac4DX:SomePlugin 2.0':
Error: Plugin Package 'SomePlugin_2_0' has no related bundle resource. [177]

This is not necessarily a problem. This is a historical item where all 4D plugins used to have to have a bundle resource. Some newer plugins do not have this bundle resource, and never will.

However -- if SanityCheck didn't complain about this before, and is complaining now, then you may have a damaged resource fork for this plugin as well... Try reinstaling the plugin. If that doesn't fix it, then contact the plugin developer and ask them about the bundle resource. If they reply they don't know what it means, have them contact us directly.

Resource File ':4D:Mac4DX:SomePlugin.4DX':
Error: Plugin 'xx_Whatever1' appears more than once. [174]
Error: Plugin 'xx_Whatever2' appears more than once. [174]

This is similar to the [209] type error, but is occuring in the plugin.

Try re-installing the plugin. If that doesn't fix it, contact the plugin developer and let them know you are having this item with their plugin. They should not have duplicates in the
plugin STR#.

SanityCheck can delete Users from a 4D Structure file -- but only ALL users, including Designer and Administer and only in one shot.

To do this, you can select "Clear All Passwords and Groups" from the Special menu item. This is usually done when the password table has become corrupted, and is why we offer it.

You'll need to re-create all your passwords from scratch after doing this.