On startup, xfix loads the handles table from the active PM_Workplace:HandlesX section in OS2SYS.INI. (See About WPS file handles for details.)

xfix then parses the handles table. For each handle that was parsed by xfix, the following information is displayed in the columns of the xfix handles list:

  1. "i" is just a count which is raised with each handle that was parsed. This number is not present in OS2SYS.INI and is not updated when you delete handles. (See "Sort by index" in the Menu commands reference.)

  2. The second column shows you the status of each handle. This is assigned by xfix. If xfix considers the handle to be OK, this column is empty.

    Already after startup, xfix checks the handles for integrity. It will detect invalid parent handles and duplicate handles immediately. If you want to have file handles marked invalid which no longer point to valid file-system information, you must first issue "Find invalid files" from the "Actions" menu.

    Every handle entry that has anything in this column is given a gray emphasis so that you can quickly see it. If you use "Select all invalid" from the "Select" menu, all those items are automatically selected for you.

  3. The "Type" field is either NODE or DRIV. If you sort by index to get the original order of items as in OS2SYS.INI, you will see that there will always be a DRIV entry before all NODE entries which belong to that drive. In addition, there is always an extra NODE entry for the root directory after the DRIV node, if any handles exist for that drive. I don't know why there is an extra DRIV node, but I guess the WPS uses it as a marker internally for finding handles more quickly.

  4. The "Node ofs" field displays the offset at which this entry (the "node") was found in the handles table from OS2SYS.INI. The table starts with four maintenance bytes (whose meaning is unknown to me), so the first entry always starts at offset 4. The length of each entry depends on its short name (see below).

  5. The "Handle" field is from the node in OS2SYS.INI and shows you the file system handle in hexadecimal, which becomes the low-word of the object handle of the corresponding filesystem object (WPDataFile or WPFolder). See About WPS file handles for details.

    There is no obvious rule for how handles are assigned. It appears that when new handles are created, they are just given a random number which is not used yet.

    This field is empty for DRIV entries because these never have handles. Again, obviously, DRIV nodes are just markers in the handles data.

  6. The "Parent" field is also stored with the entry in OS2SYS.INI and specifies the handle of the folder in which this object (either a file or another folder) resides. This better be valid (except for root NODE entries, where this is 0, obviously). If it is not, xfix marks the entry as "Orphaned" and invalid because it is no longer useful.

    The parent handle is of great importance. The WPS cannot build the full path from a file handle if a parent handle is not valid. See below for how this works.

  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, on my system, some entries are in mixed case as well. I have no idea whether this causes any problems.

  8. 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. (This still doesn't imply that it's always safe to delete the entry, since this might break shadows etc. See Deleting file handles.)

  9. The "Dups" field is also set up by xfix and counts the number of duplicates of each handle. This better be 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.

    See How can I... for more on duplicates.

  10. The "Refcs." field stands for "References" and tells you whether this handle is currently used from the OS2.INI file.

    If you see ABS in this field, this means the handle is listed in the PM_Abstract:FldrContent section of OS2.INI. That section lists the abstract objects that are present in a folder. In other words, if you see ABS, the handle is for a folder which contains abstract objects.

    If you see FPOS in this field, this means the handle is listed in the PM_Workplace:FolderPos section. That section lists all the folder positions that were ever stored by the WPS. So if you see FPOS, the entry is for a folder which has already been opened by the WPS and has had its folder position stored.

    See Deleting file handles for implications when deleting file handles which have these fields set.

  11. The "Long name" shows you the full path specification of this handle, as it would be resolved by the WPS. Note that this does not appear in the handle entry in OS2SYS.INI... instead, this displays the smartness of the whole file handles concept.

    The way this works is that when the WPS needs a full file name from an object handle (e.g. when a program object is started and the executable name is needed), it looks up the object's handle in the table, which gives it the short name (as displayed in the "Short name" column).

    The WPS then looks at the parent handle of this entry. It looks up the entry for the parent handle and prepends the short file name of the parent to the current entry. It then goes for the parent's parent... and so on, until the root node for the drive is reached. (At least this is how xfix builds the long file name.)

    This has several advantages: