WPS needs support for attributes in the underlying file system. Shell objects' attributes can be stored in a file as they are in WPS, but the files and such that poke thru the shell interface need somewhere to store their attributes. I think OS/2's solution for filesystems like FAT is a attributes file in each directory that needs one (Actually it appears to be more [link|http://www.tavi.co.uk/os2pages/eadata.html|complicated] than that). I believe MacOS X does something similar to file shares. A *n*x port would need to use a EA capable filesystem or a scheme like those listed above. Something like the later would also be needed for foriegn file systems (ie: NFS mounts). However, this brings up the next problem.

Where do you put attributes for a folder to which you don't have write permissions? Should every user have to share all of the attributes of a file? Just some of them? None of them? One possible solution to this (and the other problem too I suppose) is to keep these attributes in the same file (or another similar cache file) as the shell objects.

After playing with WPS recently, I was suprised to see how much of a self contained 'shell' over the exisitng drive letter/directory structure it really is. If one didn't care about the intermixing of (non-shadow) file system objects and shell objects, one could envision a the desktop folders and objects live in their own virtual world (ie: inside a DB file) and filesystem files are only viewed and accessed (say to create a shadow in the desktop) from file system browsers. Make the user understand there is a sepration of the two structures. But then that starts to sound like the Win3.X interface with the Program Manager let out of its window onto the desktop.