On 25/02/2021 22.26, Olaf Klinke wrote:
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.
I have no clue about stack internals, but I suspect that the only requirements regarding file system semantics are really the requirements of SQLite3. (Which is obviously what you're seeing.)
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?
Judging by the output from $ strings `which stack`|grep TMP I'm guessing you could convince the embedded SQLite3 to use a different temporary directory by setting the SQLITE_TMPDIR env var. Not sure if there are other variables of interest there. (I'm assuming you're already setting STACK_ROOT and/or your $HOME is already on the network drive.) Setting TMPDIR=/foo is respected by *many* programs, not sure about whether GHC/Cabal do.
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.
Yeah, it's a bit of a sad state of affairs that there is only one "TMPDIR" variable while there are typically /tmp -> backed by RAM /var/tmp -> backed by disk on modern Linux systems. Regards,