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:
OS2SYS.INI
and is not
updated when you delete handles.
(See "Sort by index" in the Menu commands reference.)
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.
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.
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).
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.
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.
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.
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.)
See How can I... for more on duplicates.
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.
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:
OS2SYS.INI
, which
saves space.
This is why program objects still work after folders have been moved.