Folder inaccessible after failed deployment


We occasionally run into issues where deployments fail because someone has a file open in a folder we are deploying to.
The odd part is, the folder becomes inaccessible after the failure.

We run a PowerShell script which cleans the install directory. It silently continues on errors.

First deployment

Copy package contents result:

System.UnauthorizedAccessException: Access to the path 'F:\Web\Views\Transaction\Index.cshtml' is denied.

Subsequent deployments

During delete power shell script:

Get-ChildItem : Access to the path 'F:\Web\Views\Transaction' is denied.

We cannot do anything with the folder from Windows explorer, it acts as if the folder is corrupted.

Once we kill the process which is holding a reference to the file/folder, it disappears from view and is fully deleted.


I know it is not recommended to deploy releases to the same location, but in this case we need to.

Hi AJ,

Thanks for reaching out. When you say once we kill the process, which process are you talking about? The one from the Windows explorer or some other one actually related to Octopus (i.e. a Powershell.exe process)?


Someone logged into the machine had the file open. I’m not sure what application they were using. Once I logged them off the folder was removed.

Hi Aj,

If this is being caused by a process that is not tied to the Octopus process, I’m afraid there’s not much Octopus can do in that case. Even deploying to different locations instead of a fixed one wont help if your users keep locking files by opening them.

You could attempt to programatically log off all users when you are about to deploy to that machine with something like this:

Hope that helps,