A subfolder is not allowed to exist

I'm facing an exceedingly strange situation where anytime a subdirectory is created with a specific name is being immediately deleted.

The install of ASP.NET framework 2.0 creates a subfolder at \windows\winsxs named:
x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790.

The creation succeeds but very nearly instantly that directory disappears. Same exact behavior on manual attempts to copy a folder by that name to that location. It appears for a couple seconds, then disappears.

Working with MS tech support i find that ProcMon and Windows Auditing do _not pickup the action that causes the deletion. They dragged in a security group member to search for a rootkit/viri - none found.

I _highly doubt this is DOpus's fault cuz I doubt I'm the only person with both DOpus and VisualStudio5 but perhaps folks here can explain how something like this can occur.

A junction is involved. The fact that there are references to \windows\assembly and GAC-32 come into play. But a successful workaround kinda scrambles the puzzle even more:

Simply renaming the directory where the required dll live to something besides the default name and using the junction util has eliminated the problem of IIS not finding the dll in question:

Junction C:\WINDOWS\assembly\GAC_32\System.EnterpriseServices\2.0.0.0__b03f5f7f11d50a3a C:\WINDOWS\WinSxS\stay_x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790

If the problem where _solely due to a junction malfunction - the new junction should show the same problem.

Up to a challenge? This has the MS folk stumped.

Many thx
--steve...

Does the same thing happen if you create the directory using Explorer or a command prompt?

If there is a junction involved could the monitoring tools be reporting the delete/remove as a different path that you are filtering out (mentally or via the software's configuration)?

Same behavior with Explorer.exe and cmdline.

The tech i was talking with mused about that same (correctly filtering the folder effecting/effected) subject as we were closing out our case. Since the work around works (and since they tell me i'm not infected) I'm not going to lose sleep over this till it happens again.

I've asked that tech to re-phrase and flesh out my original description - he's offline 'til next week.