views:

2115

answers:

3

The postbuild task for one of our solutions uses xcopy to move files into a common directory for build artifacts. For some reason, on my computer (and on a VM I tested), the xcopy fails with "Access Denied". Here's what I've done to try and isolate the problems:

  • I tried a normal copy; this works.
  • I double-checked that none of the files in question were read-only.
  • I checked the permissions on both the source and destination folder; I have full control of both.
  • I tried calling the xcopy from the command line in case the VS build process had locked the file.
  • I used Unlocker and Process Explorer to determine there were no locks on the source file.

What have I missed, other than paranoid conspiracy theories involving computers out to get me? This happens on my dev machine and a clean VM, but doesn't happen for anyone else on the project.

+2  A: 

Usually this happens because there's another process locking the file. I bet your machine has a different number of cores/different speed than the others. Try inserting some sleeps to see if it solves the problem.

krosenvold
Could you elaborate on the multiple cores issue? xcopy fails on the command line as well, even if VS isn't open. Tools like Unlocker claim nothing's locking the file. There's nowhere to put sleeps.
OwenP
From your description it sounds like you're in the middle of some build automation. Windows is known to be notoriously bad at this, due to file locking. I am assuming that some previous process you started in some cases is not totally finished when copying starts.
krosenvold
A: 

Try Filemon and see if it turns up any more detailed information.

jdigital
+1  A: 

Problem solved; there's two pieces to the puzzle.

The /O switch requires elevation on Vista. Also, I noticed that xcopy is deprecated in Vista in favor of robocopy. Now I'm talking with our build engineers about this.

OwenP