On startup, xfix loads the handles table from the active PM_Workplace:HandlesX section in OS2SYS.INI. (See About WPS file handles for details.) It then parses the table and displays the following information for each handle it found:
  1. "Index" identifies the order that the handles were found in OS2SYS.INI and is the table's "natural" sort order. This number is not present in handles table and is not updated when you delete handles.

  2. The "Icon" column shows the overall status for the handle: If the icon is blank, then this handle is OK and will be left as-is.

  3. The third column shows you the "Status" of each handle. This is assigned by xfix. If the Icon column displays an error or orphan icon, then this column will identify the problem. Otherwise, the column will be empty.

    During startup, xfix will detect invalid parent handles and duplicate handles. To have it identify and mark handles that point to deleted files and folders, use the "Find invalid files" command on the "Actions" menu.

  4. The "Handle" field is from the node in OS2SYS.INI and shows you the file system handle in hexadecimal. When used by the WPS, the handle you see will be prefixed with the number "3" to identify it as the handle for a filesystem object (WPDataFile or WPFolder). See About WPS file handles for details.

    The number that is used for a handle has no special meaning. When a new handle is needed, it is chosen at random from a pool of numbers ranging from 1 to 65535. This field is empty for Drive entries because these never have handles.

  5. The "Parent" field is also stored with the entry in OS2SYS.INI and specifies the handle of the folder in which this file or folder resides. If the parent handle is invalid, the WPS cannot build a file or folder's full path. xfix will mark the entry as "Orphaned" and invalid because it is no longer useful.

    The one exception to this rule is a disk drive's Root folder. It has no parent, so its parent handle is always zero.

  6. The "Type" field identifies what this handle represents. It may be a disk Drive, a Root folder, an ordinary Folder, or a File. If you sort by index to get the original order of items as in OS2SYS.INI, you will see that there is always a Drive entry, followed by a Root entry, followed by any other Folder and File entries which belong to that drive.

  7. The "Short name" is stored in the handles block and specifies the name of the file-system object without the full path path specification. The length of the file name is variable and is also the reason why each entry has a different size.

    Normally, the WPS upper-cases the short names. However, some entries may be in mixed case as well. This doesn't appear to cause any problems.

  8. The "Node ofs" field displays the offset at which this entry (the "node") was found in the handles table from OS2SYS.INI. The first entry always starts at offset 4. The length of each entry depends on its short name.

  9. The "Children" field is calculated by xfix while it is parsing the handles table. It specifies how many other entries rely on this entry because it is specified as their parent handle, either directly (as seen in the "Parent" field) or indirectly (because other parents are in between).

    If "Children" is 0, you can delete this entry without hurting other entries. If it is non-zero, you are certain to create "orphans" if you delete it. (This still doesn't imply that it's always safe to delete an entry with zero children since this might break shadows etc. See The Basics page for details.)

  10. The "Dups" field is also set up by xfix and counts the number of duplicates of each handle. This had better be zero for each handle. If it is not, the WPS will probably blow up pretty soon. That's why xfix then gives the handle the "Duplicate" status and marks it as invalid.

  11. The "References" field tells you whether certain entries in OS2.INI refer to this handle.

    If you see Abstract objects in this field, the handle is listed in the PM_Abstract:FldrContent section of OS2.INI. That section lists the abstract (non-file) objects that appear in a folder when you open it. If the handle for this folder is deleted, those objects will become inaccessible because the WPS will no longer be able to associate them with this folder.

    If you see Folder position here, the handle has one or more entries in the PM_Workplace:FolderPos section. This section is slightly mis-named since it stores the size and position not only for folder windows, but also for WPS Properties notebooks belonging to both files and folders. Consequently, it is not an error to see an FPOS associated with a file.

    You may also see something that looks like this: <WP_DESKTOP>. This comes from the PM_Workplace:Location section of OS2.INI and indicates that an Object ID has been assigned to this file or folder.

    See The Basics page for implications when deleting file handles which have these fields set.

  12. The "Long name" shows you the full path specification of this handle, as it would be resolved by the WPS. For folders, a trailing backslash is added to make it easier to distinguish files and folders. Note that the long name does not appear in the handle entry in OS2SYS.INI. Instead, xfix constructs the path using the entry's parent handle and it ancestors (see xfix and WPS File Handles for more details).