Windows intermittently unable to clear _the.. file after OpenJ9 build

[Willsparker]

Ref: adoptium/infrastructure#1379

It seems that in certain situations after a build, the workspace is unable to be cleared (using WS-CLEANUP) as openjdk-build/workspace/build/src/build/*/jdk/gensrc/java/nio/_the.. isn't able to be deleted. When attempting to remove using Windows File Explorer, the file is claimed to not be there, however it can be deleted by rming it in the Cygwin terminal.
I believe this only happens when clearing OpenJ9 builds, as the gensrc directory doesn't appear in a hotspot build.

It only seems to be when the build happens at C:/workspace/openjdk-build/, therefore only affects the softlayer machines (So possibly could have something to do with : #1724 )

[lumpfish]

I think the nightly builds do not see this issue because they run with cleanworkspace=false. When building the jdk8u262-b05_openj9-0.21.0-m1 builds cleanworkspace=true was used because the build was trying to use the wrong (cached) branch without it (on other platforms). I think that if cleanworkspace=true is used every build fails. The m1 builds only completed successfully because @Willsparker manually cleaned the workspace between each build.

[M-Davies]

@Willsparker What files specifically are unable to be cleaned by this? I'm thinking we could just add in a rm -rf <foobar> to delete the problematic files if they're in the same spot every time

[Willsparker]

It seems to be consistently the file I put above : C:/workspace/openjdk-build/workspace/build/src/build/*/jdk/gensrc/java/nio/_the.. . The way I clear it up manually is to use the cygwin terminal - so if there's a way we can force the build scripts to use that cygwin terminal, that should be okay.
I believe the plugin is attempting to remove C:/workspace/openjdk-build (as in rm -rf C:/workspace/openjdk-build) and it's just getting caught up on that one file.

[M-Davies]

The build scripts should use cygwin throughout the build so that shouldn't be the problem. I'll need to find the right place to put the code however.

[Willsparker]

Right at the beginng, presumably right after WS-CLEANUP runs - Looking at this build , an option to not fail is already turned on. So the code to remove it would need to be triggered by WS-CLEANUP failing, and subsequently remove it before it attempts to git clone again?

[Willsparker]

Yep! Should be