Hi Rich!
...Like much of XWP, It uses a mutex semaphore to protect some data that other threads modify. While this is perfectly OK, it's willing to wait indefinitely for its sem to become available. While I don't think the problem lies on this thread, it's easy to see how these indefinite waits could lead to a deadlock. Both threads A and B need to own semaphores X and Y to proceed. A holds one while B holds the other, so both wait forever for a semaphore the other will never release. If one of those threads handles populating folders, the WPS will grind to a halt. Where this is happening - if that's actually what's happening - remains a mystery...
Is this something we could try to capture? This is such a painful issue for me that I'd be more than happy to run various debug type stuff here. Also, since I have a couple of machines handy I can certainly attempt to do som more in-depth debugging, such as maybe even getting the ICAT debugger setup for this?
...BTW1... Have you ever tried disabling XWP to confirm that it really is the problem? It's easy: unlock 'xfldr.dll', rename it, then restart the Desktop. Don't rely on XWP to disable itself - this is the only method short of uninstalling that is guaranteed to do so.
BTW2... I'd still like to know what filesystems you load...
No, this I have not tried, but OK, great point, I will setup a test run to give this a go.
Ahh...filesystem...sorry, so "deep in the bowls of the beast" that it really snuck past me as well. I am exclusively running the HPFS386 setup here on local disks. 64 MB cache. Beyond that I have NetDrive active to connect to my Win and single NAS box, they use NTFS and EXT4 respectively. I am also booting with FAT32 but that only is used for my DSLR (digital camera).