If you get the File Dialog up in Poser to help it find 1 or more textures, then you'll hit the lock problem. Poser (at least 4, PP, & 5) has a memory leak or similar (surprise, surprise) in the area of code dealing with that file dialog. So if it opens up that dialog, Poser never releases it back to Windows, ergo when PBoost tries to access the directory to switch it encounters the OS lock. And Poser seems to open the search for the texture at the /Runtime level so the lock affects all directories in Runtime not just Textures. So if that's your cause, you'll need to correct those references to prevent the problem in the future. Correct Reference being the simplest way to check all files, Deep File Editor or any text editor might suffice for the individual case. Another simpler cause is that you have a directory open simultaneously in Windows Explorer or P3DO or similar. This affects just that single directory, so just re-direct the explorer-style app to another directory and try PBoost switch again. Why M$ implemented the lock this way in NTFS I'll never know, because it causes problems within the OS itself (e.g. "cannot copy file, it may be locked or in use"), but it affects W2K just the same as XP.