CODEWITHSUNDEEP
c#permissionsdirectorymove
Joran Stoops
Joran Stoops

Reputation: 163

C# Directory.Move access denied error

This is a bit of a tricky one and hopefully I can gain some insight on how the C# built in Directory.Move function works (or should work). I've written a program that puts a list of folder names that are older than a specific date into a DirectoryInfo list, which it iterates over to Move the folder elsewhere.

                foreach (DirectoryInfo temp in toBeDeleted)
            {
                filecheck.WriteLine(temp.Name);

                Directory.Move(temp.FullName, @"T:\Transactiondeletions\" + counter + "\\" + temp.Name);
            }

Where temp.Fullname is something like T:\UK\DATA\386\trans\12345678.16

However when I run the program I hit an access denied error. enter image description here

T: in this case is something like 10.11.12.13\Data2$ I have another mapped drive, U:, which is on the same IP as 10.11.12.13\Data3$ and has the exact same directory structure.

The kicker is that my program works just fine on the U drive but not on the T drive. I've tried both the drive letter in my code as the actual full path with IP, and it still works fine on the U drive but not on the T drive.

On the T drive whenever my programs tries to move a folder, it hits Access denied.

However it works fine when:

  1. I move the folder manually by hand
  2. I use a directory copy + Directory.Delete instead of Directory.Move

Any ideas? I can't figure out why it won't work here even though I can move the files manually, I've tried running the .exe manually and as admin and as a colleague as well but the result is the same.

I thought it might've been related to a streamwriter being open still (filecheck), but I've already tried moving this part of the code until after I close the streamwriter but it hits the same errors so I've 'excluded' that possibility.

Any advice would be greatly appreciated and I'll be happy to provide any more required information if necessary.

Upvotes: 4

Views: 2075

Answers (2)

back2JavaScript
back2JavaScript

Reputation: 23

There may be 2 reasons for this exception. First - file is locked by the different process i.e. Windows Explorer etc. It is legitimate exception and you have to deal with it accordingly. Second - file is locked by the same process and by the same process here I mean any thread of it. This, in my opinion is a Microsoft's bug to throw the same exception as in first case. If you look deeper, it can be branched further: same process may have another stream etc. opened in the different thread or it can be held by current thread calling Move. In the first branch I still want more elaborate exception and in the second the issue is rooted in Windows kernel. Long story short: OS seems not have enough time to release IO locks held even by the same thread following previous file/folder operation.

In order to verify my claim have a look at System.IO.Directory.InternalMove method in .NET source. Down at the end of that method there is a call to Win32Native.MoveFile which is the source of that exception. Right there you have this comment // This check was originally put in for Win9x.. That one shows how professional Microsoft developers are and that there is no feasible solution to this issue.

I had few workarounds to this: 1. Do not use Move but use Copy+Delete source. 2. Wrap Move call into the IO Utility method which would contain do while loop around try catch block containing Move call. Remember, we are only addressing a bug, where we believe same thread (or same process) holds the lock so we need to specify timeout exit condition after some number of Thread.Sleep(x) calls if file is held by another process.

Upvotes: 2

Joran Stoops
Joran Stoops

Reputation: 163

I still have no solution for the Directory.Move operation not working. however I've been able to work around the problem by going into the directory and using File.Move to move all files elsewhere, and then using Directory.Delete to delete the original directory. For some reason it works like this. But it will do!

Upvotes: 3

Related Questions