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.
Constraints
I know it is not recommended to deploy releases to the same location, but in this case we need to.
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)?
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.