If I deploy a website, then later redeploy it with the force checkbox checked, the deployment will fail because it tries to delete the target directory, like c:\Octopus\Tentacle\Applications\MyWebsite.184.108.40.206 before deploying the package. If IIS is currently serving requests from that directory, there’s a good chance the deployment will fail due to locked files. Furthermore, any IIS requests being served during the deployment will cause errors because the site is being removed out from under IIS.
For non IIS sites, the deployment will similarly fail if a Windows Service is currently running.
One way to workaround this would be to deploy to a different directory so the same behavior applies as when deploying a newer version of a package. If the tentacle detects that the target directory already exists, it could append something like “-redeploy-1” and increment the counter (or use a date).
In fact, always appending the date/time when the deployment started to the target directory could cleanly make sure that redeploys always go to a new directory while preserving a consistent directory naming scheme.
Of course this should not apply if the configuration specifies an override for the OctopusPackageDirectoryPath variable.