Yes, NFSv3 client side locking works pretty well so long as no shared concurrent write happens. A single node's os would assume successful lock for it to write to a file, when multiple nodes do this concurrently, the file will be corrupted. As with stack it can happen and rendering the tool unusable.

But NFSv4 server side locking can leave dead locks appear live, leading stack to wait forever. So we stay client side locking, and carefully have each node use different path on the shared storage for .stack folders, then reinitialize it in case corrupted by accident.

On 2021-02-25, at 23:59, Sven Panne <svenpanne@gmail.com> wrote:

Am Do., 25. Feb. 2021 um 15:59 Uhr schrieb Olaf Klinke <olf@aatal-apotheke.de>:
Speaking of which, is there a specification about what filesystem
features stack and its sub-tools expect? I can not build stack projects
on a remote cifs share, but on the local filesystem it works fine. The
error is

Encountered error while migrating Stack database:
    SQLite3 returned ErrorBusy while attempting to perform step:
database is locked
Please report this on https://github.com/commercialhaskell/stack/issues
[...]

In ancient times, locking over NFS didn't work, or at least not reliably. With NFS 4, locking was added to the protocol IIRC, but I have no clue how good it works, especially when you mix various platforms/implementations. What the current state with CIFS regarding locking is: I don't know, but in general I don't really trust remote file systems in this area. :-}
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.