What's causing xcopy to tell me Access Denied?

Question

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.

Solution 1

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.

Solution 2

/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

Solution 3

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".

Solution 4

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.

View more solutions

Comments

[krosenvold]

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.

[ziddarth]

Thanks, this helped me.

[Juan Manuel Perez]

That also solved the problem for me, even when the destination file was not showing up as 'readonly'....