On Thu, 2021-02-25 at 16:59 +0100, Sven Panne 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. :-}
Thanks for the clue. So what exactly is "locking" on the file-system level, then? I searched and found the term "oplocks" and that this is an option for cifs. Which state does stack need? oplock=on or oplock=off? My SMB server currently has oplock=on. Tried toggling it, still same SQLite3 locking error. And yes, I'd rather sooner than later switch over to NFS 4, but I have to sort that out on my NAS. It's a pity, my approach was to have as much of my Haskell stuff on a NAS as possible, so I wouldn't run into disk space issues. But this and the fact that stack/ghc stubbornly insist on using local dirs like /tmp make this hard. Has anynone else here successfully built a stack project on a cifs share? Olaf P.S.: Yes, I even re-mapped /tmp to another partition once to bootstrap ghc because it would occupy my entire tmpfs. But it would be nice if one could do without such tricks.