VS Code Remote - SSH: difference between "Lockfiles in Tmp" and "Use Flock"?

I am trying to use the VS Code extension Remote - SSH (v0.63.0) to develop C/C++ code on a remote system.

The remote system is a cluster of tens of Linux (Ubuntu 14) machines using OpenAFS.

I have run into a problem:

Initial connection: works fine
Further attempts fail, it times out during retries

To solve, I would delete the .vscode-server folder, change extension settings, and try reconnecting a few times. Ultimately, I have learned of two possible solutions:

"remote.SSH.useFlock": false
- This solved the problem for me
"remote.SSH.lockfilesInTmp": false
- Suggested by a peer using the same file system, I didn't try this

What (in practice) is the difference between the two? Which is the better choice?

Aside: SSH config

Host foo foo.bar.addr
  HostName foo.bar.addr
  User qux
  ControlMaster auto
  ControlPath ~/.ssh/%r@%h:%p
  ControlPersist yes

Solution

<total conjecture>It sounds like the locks are getting stuck even when the server closes. So on reconnect vscode won't start a new server (because of the lock) but can't connect to the "existing" server because it's already closed</total conjecture>

That's where this first option "remote.SSH.useFlock" comes in. It controls whether vs code uses the flock system call or ln to lock files. Setting this will clean up most issues you could have with mounts that might have issues support flock.

The second option "remote.SSH.lockfilesInTmp" re-locates the lock files completely (moving them to tmp) because some mounts (like SSH) may have issues even with the ln approach to locking. The downside here is that this moves lock files way from the actual install. So if there's a risk that install may be shared (NFS, shared home, link to shared area, etc.) then vscode may "miss" locks.

If "remote.SSH.useFlock": false works for you I would keep that.

If you need to use "remote.SSH.lockfilesInTmp": true take care to avoid running multiple servers out of the same install.