aboutsummaryrefslogtreecommitdiff
path: root/internal/fusefrontend/file_lock.go
AgeCommit message (Collapse)Author
24 hoursfusefrontend: LockSharedStorage: loop on EINTR, add debug outputJakob Unterwurzacher
24 hoursfusefrontend: sharedstorage: introduce UnlockSharedStorage helperJakob Unterwurzacher
24 hoursfusefrontend: sharedstorage: lock truncate agains concurrent accessJakob Unterwurzacher
Prevent reads and writes concurrent with the truncate operation. It's racy on tmpfs and ext4 ( https://lore.kernel.org/all/18e9fa0f-ec31-9107-459c-ae1694503f87@gmail.com/t/ ) as evident by TestOpenTruncate test failures: === RUN TestOpenTruncate cluster_test.go:209: POSIX compliance issue: non-exlusive create failed with err=file exists doRead 16384215: corrupt block #0: cipher: message authentication failed ino16384215 fh8: RMW read failed: errno=5 cluster_test.go:214: iteration 1: WriteAt: write /tmp/gocryptfs-test-parent-1026/1358464214/TestOpenTruncate.1788296708.mnt2/foo: input/output error --- FAIL: TestOpenTruncate (0.06s) FAIL exit status 1 FAIL github.com/rfjakob/gocryptfs/v2/tests/cluster 7.880s Relates-to: https://github.com/rfjakob/gocryptfs/issues/56
25 hoursfusefrontend: sharedstorage: use byte-range lock on file header creationJakob Unterwurzacher
Multiple host writing to the same empty file at the same time could have overwritten each other's newly created file header, leading to data corruption. Fix the race by placing a byte-range lock on the file when creating the file header.