sbt wrongly prints "sbt server is already booting"

Further information:

At least in my specific case, doing [System.IO.Directory]::GetFiles("\\.\\pipe\\") in PowerShell gives me:

\\.\\pipe\\sbt-load-9219294593538022506_lock
\\.\\pipe\\sbt-load-9219294593538022506

In this case, it seems that once there’s one instance of SBT, whether alive or ghosted, it would not release this lock, but the logic in booting the server does not seem to release this lock; perhaps in Windows the IPC behaviour is different from that on UNIX?

I also built my own local SBT to throw the full stack trace and it looks like this:

sbt thinks that server is already booting because of this exception:
java.io.IOException: Could not create lock for \\.\pipe\sbt-load-9219294593538022506_lock, error 5
Create a new server? y/n (default y)
sbt.internal.ServerAlreadyBootingException: java.io.IOException: Could not create lock for \\.\pipe\sbt-load-9219294593538022506_lock, error 5
        at sbt.internal.BootServerSocket.newSocket(BootServerSocket.java:348)
        at sbt.internal.BootServerSocket.<init>(BootServerSocket.java:294)
        at sbt.xMain$.getSocketOrExit(Main.scala:145)
        at sbt.xMain$.bootServerSocket$lzycompute$1(Main.scala:77)
        at sbt.xMain$.bootServerSocket$1(Main.scala:77)
        at sbt.xMain$.withStreams$1(Main.scala:85)
        at sbt.xMain$.run(Main.scala:121)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at sbt.internal.XMainConfiguration.run(XMainConfiguration.java:56)
        at sbt.xMain.run(Main.scala:46)
        at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:111)
        at xsbt.boot.Launch$.withContextLoader(Launch.scala:131)
        at xsbt.boot.Launch$.run(Launch.scala:111)
        at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:37)
        at xsbt.boot.Launch$.launch(Launch.scala:120)
        at xsbt.boot.Launch$.apply(Launch.scala:20)
        at xsbt.boot.Boot$.runImpl(Boot.scala:56)
        at xsbt.boot.Boot$.main(Boot.scala:18)
        at xsbt.boot.Boot.main(Boot.scala)
Caused by: java.io.IOException: Could not create lock for \\.\pipe\sbt-load-9219294593538022506_lock, error 5
        at org.scalasbt.ipcsocket.Win32NamedPipeServerSocket.<init>(Win32NamedPipeServerSocket.java:129)
        at org.scalasbt.ipcsocket.Win32NamedPipeServerSocket.<init>(Win32NamedPipeServerSocket.java:48)
        at sbt.internal.BootServerSocket.newSocket(BootServerSocket.java:342)
        ... 21 more

Since a _lock pipe already exists, should it actually try to create another one? Because when it tries to create a new one, that is when it will try to create a file, and then cause this error 5 which corresponds to Access Denied (I would imagine it would deny access to create a pipe on top of one that already exists).

The other server in this case is booted already, rather than booting, so the ServerAlreadyBootingException does not describe the situation correctly

FYI with sbt 1.4.9 in a Docker image running ubuntu 16.04, the exception I get is

java.io.IOException: org.scalasbt.ipcsocket.NativeErrorException: [22] Invalid argument

I was able to successfully workaround the issue by adding the --batch argument too, i.e. sbt -Dsbt.server.forcestart=true --batch ...