
              Discussion of UNIMAINT Repair Capabilities

UNIMAINT has an item on the Recover menu called Repair. This item gives
the user the ability to perform a number of different automatic Repair
actions on his INI files. The On-line Help documents how the Repair
function works, however, it does not detail the rational and algorithms
employed by UNIMAINT to accomplish the various Repairs. This document
is an attempt to do that.

                          General Information

Type of Repair

There are four different type of Repair Options.

The first one, Report Only, will never make any changes, but will only
list the items that would have been Repaired if the Do Repair Option
had been chosen.

The Ask First, will ask the user if he wants each item repaired as the
item is found and determined to be invalid. This can take a very long
time in some cases, since the number of items can become quite large

Do Repair, will automatically remove all invalid items for the category
selected from the appropriate INI file. This should only be used when
the user is sure he wants all invalid items removed.

Do Selected can only be used after Report Only, since it requires that
the invalid items be visible in the window. When Execute is chosen with
the Do Selected button checked, then every line in the window that is
selected will be deleted. The only exception to this is when doing
either the Handles or WPS repair and a selected item has dependent
items, such as subdirectories or files, in this case all dependent
items will also be deleted. For example, if a Drive name itself is
selected and Do Selected is chosen, then all entries for the drive,
including all directories and files, that have been identified as
invalid will be deleted.

The easiest and safest way to remove invalid items when the user is not
sure if they want everything done is to use the Report Only option,
select the items that they want deleted and then use Do Selected. This
cycle can be repeated over and over until all of the desired items have
been deleted.

                            Window Behavior  

When and item is deleted for any reason, the word 'Deleted' will appear
after the item in the window. If there are deleted items in the window
and additional items are selected for deletion then the previously
deleted items will be removed from the window. For example, if the
first item in the window is selected and deleted, the word deleted
would appear after the first item. If then the second items is selected
and deleted, the second item will now have the word deleted after it
and the first item will be gone from the window.

                                Options

Different users want to handle directories and file that are on
removable, not ready, cdrom and vdisk devices differently. The Options
dialog gives each user the ability to choose how they want each of
these types of situations handled.

If Ignore is chosen, then directories and files on the appropriate type
of device will be completely ignored and will never appear in the
repair window.

If Report Only is selected, then the information will appear in the
window, but will not get automatically deleted if the Do Repair option
is chosen. The Report Only items can still be deleted by selecting them
and using the Do Selected option.

If Auto Repair, which is the default, is chosen, then the items will be
reported and will be automatically deleted if Do Repair is chosen.

The Do Not Save Deleted Items button will cause UNIMAINT to not save
items that are deleted from an INI file in the Save INI File. Normally,
the user must specify a Save INI File and any entries removed from any
INI file are written to the Save INI File before they are modified.
This allows the user to restore items that he has deleted if they
discover that something has been deleted in error and no backup is
available.

The Log to INIREP.LOG is used for diagnostic purposes.

                 List Items versus Repair Items

For a number of the repair categories there are multiple choices
available. The is always the Repair choice and it works the same for
each category of Repair. When the Repair choice is used, the only items
that will appear in the window will be items that are invalid and
should be deleted.

If the user want to see the valid items for the category or all the
items, then the appropriate List entry can be used to display these
entries. The List Invalid items is the same as the Repair as far as the
contents of the window is concerned, however, it is safer because it is
not possible to select or otherwise delete any of the items.

                        Type of Repair

Repair Path and Filenames

Many, if not all, applications installed under OS/2 store things in
various INI files. However, few, if any, applications will remove
things from these files when they are deinstalled or the directory
structure is changed. This Repair action looks at the Pathname and
Filename entries in an INI file, compares them to the current Desktop
and either identifies and/or removes entries that are obsolete.

The action UNIMAINT will take depends on the structure of the
individual Key Name or Key Value. There are two possibilities that
UNIMAINT looks for:

   1. A Filename with no preceding Path information.   

   2. A full Pathname or Filename combination.

Each of the above are handled differently.

General Processing applicable to both type of names:

Any name that is too short, less than 3 characters, or too long, longer
than the maximum path length returned by DosQSysInfo, will not be
tested further.

Any name which contains non-printable characters will not be tested.

Processing of Filename with no Path information:

If the beginning of a Key Name or Key Value starts with either X:\ or
just \, UNIMAINT assumes it is a full Pathname or Filename and
processes it as described below. UNIMAINT will then check for a
Filename of the form *.XXX and ignore them, since this is simply a
definition of a type of file extension and not an actual file. UNIMAINT
will then look for .XXX as the last four characters of the Filename and
will search for the following combinations:

   1. .EXE using the PATH Environment variable.   

   2. .CMD using the PATH Environment variable.   

   3. .DLL using the LIBPATH Environment variable.   

   4. .HLP using the HELP Environment variable.

Processing of full Pathname or Filename:

If the name starts with \, then the drive used as the drive for the
OS2.INI file, which is the boot drive, will be appended to the start of
the name.

Any name that starts with A: or B: will be ignored, since they are
assumed to be floppy drives and probably do not contain any media.

Any trailing semicolons are removed from the name, since there are a
number of entries that are valid Filenames except for the semicolons.

If the trailing character in the name is a \ or if the name contains
any embedded semicolons, it will be tried as a Pathname and made a
candidate for removal if it is not found.

All other qualifying names will be tried as both a Filename and a
Pathname and will be made a candidate for removal if they fail both
tests.

Repair Objects

Most, if not all, of the items on the Desktop have been assigned an
Object Number. This number along with the name of the Object is stored
in the OS2.INI file. This Repair entry will display and give the user
the option to delete and Object. It is not currently possible for
UNIMAINT to determine which Objects are valid and which are invalid, so
UNIMAINT will never identify an Object as invalid. Great care should be
exercised when deleting any of the Objects, since it is possible to do
serious damage to your Desktop.

The structure which stores all of the Object cross reference is used by
the WPS Repair code to determine if Objects are valid and to find the
names of valid Objects.

Repair Directory/File Handles

Many Drives, Directories and Files are assigned Handles. This Handle
information is stored in the OS2SYS.INI file. However, when files are
moved, directories changed or other changes are made to the Desktop,
the Handle information is not updated. This Repair option gives the
user the ability to see the contents of the INI file Handles entry and
Repair any or all of the invalid entries.

It is difficult to remove incorrect information manually, even knowing
the internal structure of the entries, because all of the Handles
information is stored in a single INI file entry and a small mistake in
modifying could cause serious Desktop problems and/or create a
non-bootable situation.

The structure which stores all of the Handles information is used by
the WPS Repair code to determine if Handles are valid and to find the
names of Directories and Files.

Repair WPS Entries

WPS stores a variety of Desktop information in the INI files. As with
the Handles information above, obsolete information is not always
removed from the INI files when changes are made to the Desktop. This
Repair option gives the user the ability to see what is in his INI
files and remove those entries that are invalid.

As with the Handles above, it is difficult to make these changes
manually because things are stored in a number of different formats and
the cross reference between the random looking numbers and the actual
Objects and Handles would be very tedious to track manually.

The Repair WPS Entries uses the Objects and Handles structures. This
means that these structures must be filled before the WPS structure can
be filled. This can take a significant amount of time in situations
where the Desktop is complex and/or there are a large number of invalid
entries.

Repair Both WPS and Handles Entries

This is simply a combination of Repair WPS Entries and Repair
Directory/File Handles above. It allows the user to do both types of
Repair with a single action.
