Unit test failing due to surefire plugin's forkmode

Question

There is a test in my code which creates a directory and then creates a file inside it.

However, this test fails as the portion of the test that writes the file is not able to find the directory that is created. The only thing that fixes it is to set the surefire plugin to never fork like so:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <forkMode>never</forkMode>
    </configuration>
</plugin>

I would interpret this fix to mean that the directory is created in one JVM process and the file is created in another JVM process/thread ?

This test failure is isolated to a single machine on which it has started failing only recently.

A couple of things that I have tried are :

1. There were numerous JDK versions floating around on the system, so got rid of all except the one that was working on a number of other systems ( 1.6.0_19 ).
2. Tried running the 'mvn test' on that project from an Administrator cmd prompt.
3. Checked that the permissions of the parent directory are fine.
4. Tried checking out the whole project from scratch and doing the same.
5. Checked that the directory where this was happening was excluded from AntiVirus' On-Access-Scanner.

None of the above seem to have any effect. The only thing that makes a difference is the <forkMode> config. I can't figure out why that test suddenly stopped working when there have been absolutely no code changes around it or in the functionality that it's testing.

The version of maven-surefire-plugin being used is 2.12.4. Updating to the latest (2.14.1) does not fix the test if the `never' config is missing.

<forkMode> is deprecated but only since version 2.14.

I am really intrigued by what the underlying issue might be. I am hoping that the final conclusion is not something as simple as this being a HDD or hardware issue.

Answer 1

tl;dr : Fixed !

Another brand new machine was built for the user. It worked fine for an hour or so and then after that, lo and behold, the exact same issue.

The general consensus was that it MUST be a rogue windows update. So we tried a couple of things, like restoring the machine to a previous state. Uninstalling windows updates manually etc. Nothing worked.

Then the owner of the machine had an epiphany. Apparently, he had gotten used to this registry hack, which was the reason for this uber mysterious error. We undid that, and voilà the mvn clean install worked fine !

I am still very curious though about why it would affect a java process, so here is a follow up question around it : Why does this autorun-cmd registry hack affect a java/maven process? (Complete with a gihub repo to isolate the offending code.)

Thanks for all the helpful comments.