Try to run the following pipeline on a Windows node (you'll need a Unix shell port; I am using bash from Git for Windows):
The bat step will fail with an "Access is denied" message.
It seems that the reason for this is that when the Durable Task plugin runs its wrapper script (in BourneShellScript.launchWithCookie), it doesn't wait for the wrapper process to finish before it allows pipeline execution to proceed to the next step. It only waits until the result file gets created. This means that for a fraction of time, the bat step will be running concurrently with these three processes created for the sh step:
- The wrapper script.
- The nohup process that is its parent.
- The background job that the wrapper script creates to periodically touch the log file.
And that fraction can be significant, because the background job sleeps in intervals of three seconds.
Now, those processes have as their working directory the directory of the sh step, which on Windows means that that directory is locked - it cannot be deleted, and its parent cannot be moved. And since the bat step starts executing before those processes terminate, it cannot rename the foo directory, even though it really should be able to.
To solve this, ideally, the Durable Task plugin should wait for the nohup process to terminate before proceeding with the next step. Failing that, it should at least make sure that the working directories of the auxiliary processes it spawns aren't within the workspace.
(I'm unable to easily test this using the most recent version of the plugin, but I reviewed the changes made since 1.22 and I'm fairly confident that the latest version still exhibits this issue.)