aboutsummaryrefslogtreecommitdiff
path: root/internal/fusefrontend/file_lock.go
AgeCommit message (Collapse)Author
2024-12-30fusefrontend: sharedstorage: lock truncate agains concurrent accessLockSharedStorage_rebase1Jakob 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
2024-12-04fusefrontend: 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.