On my Win7 32-bit system (fully patched), I have run into a problem with Visual Studio 2010 Express compiling a C program. The program is small and I can rapidly make changes to the source file, compile/link it with the CL command in the command line window, and perform a test run the program.

The problem is that on the 2nd or 3rd run of the CL command, the *.exe file can't be written to (security error). Using the dir command, the file is still there but from the previous CL output. The command dir /q shows why. The owner has been changed from my userid to '...' If I wait 5-10 minutes, the file goes away on its own. If I use Windows Explorer to move it to the trash, it comes back. If I highlight file and use shift-deletee to remove it, the file comes back. Eventually, after the above mentioned wait time, the file does go away.

I started using a workaround, to rename the specific *.exe file to aaa. Then, CL runs fine, but now I can't delete file aaa. So, move on to file rename the specific *.exe file to bbb. Eventually, I have many files in the directory, all with owner userid changed to '...', that if I wait long enough, they do go away.

Does anybody have a clue why delete does not remove these files, but simple changes ownership from my userid to '...' (display byed the dir /q command)?

I have turned off my firewall and anti-virus and that changed nothing. Same result.

Running Visual Studio 2010 in administrator mode changed nothing.

Opening a regular command window and deleting the file, produced the same result.

Is this a result of some screwy behavior in file shadowing? The directory for the programs is on the boot drive with shadowing turned on.

Appreciate any feedback that anyone can offer.