The Workplace Shell uses file handles as an internal database to be able to find files no matter of their physical location.

In principle, these file handles are a good thing. It is file handles which allows for the WPS's superior features of program objects and shadows working even after the files they point to have been moved to a different location. Basically, this works because program objects and shadows never store the physical path of an object, but only an object handle.

Object handles are 32-bit integers which are supposed to be unique on the system. The high-word of the integer signifies the storage class of the object while the low-word is a unique identifier within that storage class.

To understand where all those file-system handles come from, some more understanding of the WPS's inner workings is required.

In theory, the WPS should only create a handle for a file-system object if this is really needed, i.e. the object was really referenced somewhere. I guess this was the original design when the WPS was first created for OS/2 2.0. (Again, this is only a problem for file-system objects, since per definition, abstract objects must have a handle.)

For example, if you enter a path to an executable file in a program object's settings notebook, the program object wants a handle, so it should get a new one when no one exists yet. The same applies to shadows.

So again, in theory, object handles are a great thing. However, there are several problems with the implementation of them in the WPS:

From my testing, file handles are created in the following situations (in which the aforementioned API is called): It is very difficult to solve the problems mentioned above because no public APIs exist to hack the WPS's behavior with respect to file-system handles or the folder auto-refresh. I am working on replacements to these subsystems to &xwp;, but until then external tools such as CHECKINI and xfix are the only solution.