23

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.

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
OwenP
  • 24,950
  • 13
  • 65
  • 102

6 Answers6

26

/r = Use this option to overwrite read-only files in destination. If you don't use this option when you want to overwrite a read-only file in destination, you'll be prompted with an "Access denied" message and the xcopy command will stop running.

That's was mine resolution to this error.

Source

Tamir
  • 3,833
  • 3
  • 32
  • 41
18

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
  • 24,950
  • 13
  • 65
  • 102
6

You need to run XCOPY as Administrator, there is no way around this.

If you don't want to run your copy as Administrator, then you must use ROBOCOPY instead.

Note, however, that with ROBOCOPY it is very tempting to use the /COPYALL switch, which copies auditing info as well and requires "Manage Auditing user right", which again invites you to run as Administrator as a quick solution. If you don't want to run your copy as Administrator, then don't use the /COPYALL (or /Copy:DATSOU) switch. Instead use /Copy:DATSO, as the U stands for aUditing.

Also note that if you are copying from NTFS to a FAT files system, there is no way you can "Copy NTFS Security to Destination Directory/File".

iNoob
  • 151
  • 1
  • 5
1

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
  • 75,535
  • 32
  • 152
  • 208
  • 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 Mar 18 '09 at 18:22
  • 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 Mar 18 '09 at 19:22
0

If you can delete the file in Windows Explorer, try using an elevated command prompt. Not sure why Windows Explorer does not ask permission here for a delete operation that needs admin rights via cmd.

sennett
  • 8,014
  • 9
  • 46
  • 69
0

if you are copying file to IIS folder, then you need run the batch file as admin.

Alper Ebicoglu
  • 8,884
  • 1
  • 49
  • 55