This works because program objects and shadows never store the physical path of a file or folder, just its handle. When the WPS needs the full path, it is built piece by piece from the handles for each part of that path.

The WPS starts by looking in the table for the file handle it got from the program object or shadow. The entry for that handle provides the file's name (as displayed in xfix's "Short name" column), along with the handle for the parent folder containing this file. The WPS then looks up the parent folder's handle, gets its name, and adds it (along with a backslash) to the begining of the path. It then goes for the parent's parent... and so on, until the root folder for the drive is reached.

This has several advantages:

• Only the short name has to be stored in OS2SYS.INI, which saves space.
• More important, this is very efficient when files or folders are moved because only the parent handle of the object being moved has to be updated. Since all sub-objects of the item being moved only contain a parent handle, the next time the full file name is needed, it can be correctly built with the new path.

Unfortunately, this also has several disadvantages:

• The WPS never deletes handles, even when the files or folders they refer to are deleted.
• The WPS creates handles for files that will never be used by program objects or shadows (such as DLLs or ZIP files).
• Bugs and/or crashes in the WPS can corrupt the handles table, leaving you with duplicate entries for a handle, entries that point at the wrong file or folder, etc.