-1

I wonder if anyone else is having a similar issue.

I have a simple file copy code in my application, which can be simplified as below (and my user I opened VS2013 to debug the code has full control on both the source and target folder hierarchy - this wasn't so for some reason, I tried running VS in admin mode which didn't work, then I manually applied full-control to the user, and anyways the error complains about the source folder)

// sourcefile was thought to be @"C:\tfs\Dev\Source\some-module\bin\Debug\mybinary.dll";
// retrieved through an environment variable, but was pointing to the folder instead of the file inside
Directory.CreateDirectory(myfolder);
File.Copy(sourcefile, Path.Combine(myfolder, Path.GetFileName(sourcefile)), true);

This code worked happily until I tried it today on my local machine (and still works on my testbed machine). But for some reason, it started throwing the error below:

System.UnauthorizedAccessException: Access to the path 'C:\tfs\Dev\Source\some-module\bin\Debug' is denied.
Result StackTrace:  
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)

Thinking it may be a file-lock issue I rebooted and tried it again afresh but failed.

The folder for source has Read-only attribute and thinking this may be a problem (which is weird), I started trying unsetting it but cannot. Then I moved the folder out of the tfs workspace to another folder (under c:\users\my-user..) and still cannot remove the read-only attribute (it seems to work, but checking again shows the same attribute on the file). I even frantically tried unsetting read-only on all the parent folders then gave up as it's in vein. And must not be in any way related to the original problem.

I double-checked similar so questions and thoughts and am running out of options.

Win7, .net 4.5.2, VS2013 are some configurations.

additional experiments, update I tried using Directory.CreateDirectory on the sourcefile directory with security rules with full permission to current user, doesn't change anything. Why would it complain about the sourcefile directory to start with??

AlbusMPiroglu
  • 645
  • 3
  • 13
  • 5
    it means that the current user does not have permission to write in that directory. First set the permission the user account on which you are running application. – Niranjan Singh Aug 09 '16 at 02:41
  • 1
    Suggestions: a) Check file does not exists on destination; b) sleeep one second and retry as AV may be scanning the file and temporary blocking access – Jorge Rojas Aug 09 '16 at 02:47
  • Niranjan, I alread mention in first paragraph about the full control to the user. Jorge, good idea about the AV, I'll check it! – AlbusMPiroglu Aug 09 '16 at 04:03
  • Check both above cases and give permission to folder as everyone attribute. and than disable av it may fix your issue. – Piyush Barua Aug 09 '16 at 05:44
  • 2
    Either delete it or, if (as it sounds) you think this *could* be useful for others in the future, write a good *answer* and add it here. Answering your own questions is a supported concept on SO, but you should put the answer *as* an answer, rather than hiding it in an edit to your question. And if you think the question may have misleading aspects, also edit that to improve it. – Damien_The_Unbeliever Aug 09 '16 at 06:51
  • Correct. I just did. Apologies for any confusion. – AlbusMPiroglu Aug 09 '16 at 12:02

2 Answers2

0

Could it be that the file is blocked? If it's downloaded from the Internet, Windows will block it. Then you need to go to the file's properties, and at the bottom you will find a checkbox where you can unblock it.

Blocked file

Henning
  • 39
  • 3
0

Hmm. It happened again. Mistake at another place.

The simplified code I put down in the question didn't show the actual one. I was using an environment variable for the source file name, and turned out it was pointing to a folder, not a file.

I think the problem here is Microsoft's UnauthorizedAccess is not intuitive enough to understand that you actually tried to copy a directory instead of a file, and you start chasing your tail as a result. Anyways, here's a case that may help someone else. Don't forget to check if it's a directory or a file that you're copying.

AlbusMPiroglu
  • 645
  • 3
  • 13