On Wed, Jun 02, 2021 at 07:06:59PM +0000, Simon Peyton Jones via ghc-devs wrote:
"/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force --global-package-db "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update rts/dist/package.conf.install
ghc-pkg: Couldn't open database /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for modification: {handle: /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)
With WSL2, what sort of filesystem is /home/<username>? Is a native Linux filesystem (ext4, btrfs, ...) over a block device, or is it NTFS (either shared with Windows or dedicated for WSL2)? The "hLock" function in GHC.IO.Handle.Lock makes use of a "lockImpl" handle that on linux typically expects to find working support for the sane "open file descriptor locking", which avoids historical POSIX lock breakage by using: F_OFD_SETLK F_OFD_SETLKW F_OFD_GETLK The supporting is in GHC.IO.Handle.Lock.LinuxOFD. It appears that F_OFD_SETLKW is failing on WSL2 with EINVAL. It is not clear whether the issue is lack of support for F_OFD_SETLKW in the fcntl(2) implementation, or something about the structure that's passed to acquire the lock: instance Storable FLock where sizeOf _ = #{size struct flock} alignment _ = #{alignment struct flock} poke ptr x = do fillBytes ptr 0 (sizeOf x) #{poke struct flock, l_type} ptr (l_type x) #{poke struct flock, l_whence} ptr (l_whence x) #{poke struct flock, l_start} ptr (l_start x) #{poke struct flock, l_len} ptr (l_len x) #{poke struct flock, l_pid} ptr (l_pid x) peek ptr = FLock <$> #{peek struct flock, l_type} ptr <*> #{peek struct flock, l_whence} ptr <*> #{peek struct flock, l_start} ptr <*> #{peek struct flock, l_len} ptr <*> #{peek struct flock, l_pid} ptr or perhaps an issue with locking generally for the filesystem in question. Whether the lock is per open file or per file object across all its open instances (POSIX breakage) should not depend on the filesystem type, so if locking works with F_SETLKW, it should also work with F_OFD_SETLW, provided the latter is supported at all. It should be possible to test lock support on WSL2 with a simple program (source attached), compiled via: $ make CFLAGS=-D_GNU_SOURCE ofdlock and executed (with CWD in the relevant filesystem): $ ./ofdlock ofdlock.dat Size of struct flock = 32 l_type ofset = 0 l_whence ofset = 2 l_start ofset = 8 l_len ofset = 16 l_pid ofset = 24 This should not report any errors, and should return a size and structure offset values that match the upstream compilation environment. -- Viktor.