msbuild “Unable to remove directory”

Question

One of our CruiseControl.NET projects keeps intermittently failing because a msbuild task fails with

error MSB3231: Unable to remove directory "d:\Somewhere\Dir\Admin". The parameter is incorrect.

The corresponding msbuild script line is just

<RemoveDir Directories="$(DistributionDir)\Admin" Condition="Exists('$(DistributionDir)\Admin')" />

When I look at the state after the failed build, the directory contents was removed successfully, but the empty directory itself is left there. And the next build usually succeeds (having to remove just the empty directory). Note that the problem does not seem to be the usual “some other process (like antivirus) keeps locking the directory”, the error is not “access denied”, but a very strange “the parameter is incorrect”.

I monitored the build with SysInternals Process Monitor, and the result is strange – everything goes as expected, the contents of the directory is enumerated, deleted, and when the top-level directory enumeration finishes with “NO MORE FILES”, the directory is closed, and… nothing. No other operation gets to the process monitor:

10:04:09,9190557    MSBuild.exe 3516    QueryDirectory  D:\Somewhere\Dir\Admin  NO MORE FILES   
10:04:09,9190928    MSBuild.exe 3516    CloseFile       D:\Somewhere\Dir\Admin  SUCCESS 

The next (successful) build attempt is just a boring successful directory removal:

10:31:21,8616463    MSBuild.exe 1760    CreateFile  D:\Somewhere\Dir\Admin  SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
10:31:21,8616861    MSBuild.exe 1760    QueryDirectory  D:\Somewhere\Dir\Admin\*    SUCCESS Filter: *, 1: .
10:31:21,8617305    MSBuild.exe 1760    QueryDirectory  D:\Somewhere\Dir\Admin  SUCCESS 0: ..
10:31:21,8617589    MSBuild.exe 1760    QueryDirectory  D:\Somewhere\Dir\Admin  NO MORE FILES   
10:31:21,8618209    MSBuild.exe 1760    CloseFile   D:\Somewhere\Dir\Admin  SUCCESS 
10:31:21,8621579    MSBuild.exe 1760    CreateFile  D:\Somewhere\Dir\Admin  SUCCESS Desired Access: Read Attributes, Delete, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
10:31:21,8622118    MSBuild.exe 1760    QueryAttributeTagFile   D:\Somewhere\Dir\Admin  SUCCESS Attributes: D, ReparseTag: 0x0
10:31:21,8622408    MSBuild.exe 1760    SetDispositionInformationFile   D:\Somewhere\Dir\Admin  SUCCESS Delete: True
10:31:21,8622676    MSBuild.exe 1760    CloseFile   D:\Somewhere\Dir\Admin  SUCCESS 

It seems for some reason, MSBuild/Windows detects some kind of invalid parameter error before the directory removal is executed, but I have no idea where to look. (I have also tried to run chkdsk, nothing was found. I have also removed and recreated the parent D:\Somewhere\Dir directory, nothing changed.)

So – any idea where the problem could be or how should I investigate further?

(I am not sure where this question should have gone, it is kind of somewhere between SO, Progs SE, Server Fault, Superuser…)

Answer 1

Tried a lot of things, but I couldn't figure out why this sometimes fails when the directory isn't empty; in our case the directory contains symbolic links if that matters. Anyway I don't like using ContinueOnError since that means when there is an actual error you don't know it, or have to do an extra check like <Error Condition="Exists... after every RemoveDir. The solution we use now is to explicitely empty the directory, after which msbuild doesn't seem to have any problems removing it:

<MSBuild.ExtensionPack.FileSystem.Folder Condition="Exists( $(PathtoEmpty) )"
   TaskAction="RemoveContent" Path="$(PathtoEmpty)" />
<RemoveDir Directories="$(PathtoEmpty)" />

Answer 2

I can't say why it is failing, but if the folder is the only thing left over can the build complete correctly? If so, a workaround would be to specify ContinueOnError="True".

Answer 3

I've just encountered this error myself, it turned out that I had the offending folder opened in a Windows Explorer and that prevented it from being properly deleted.