gocryptfs - Mirror of gocryptfs source code on Github

Age	Commit message (Collapse)	Author
2023-06-09	tests/cluster: enable TestClusterConcurrentRW per default	Jakob Unterwurzacher
	Add the -sharedstorage flag to the mounts and make it more severe by adjusting the I/O and file sizes to arbitrary unaligned values. It passes most of the time. If it fails, it's like this, and the reason is that there is no fcntl locks in the READ path yet. gocryptfs/tests/cluster$ go test -run TestClusterConcurrentRW -v === RUN TestClusterConcurrentRW doRead 2895433: corrupt block #0: cipher: message authentication failed doRead 2895433: corrupt block #0: cipher: message authentication failed doRead 2895433: corrupt block #0: cipher: message authentication failed cluster_test.go:98: readThread iteration 9165: ReadAt failed: read /var/tmp/gocryptfs-test-parent-1026/3021427391/TestClusterConcurrentRW.366469887.mnt1/foo: input/output error --- FAIL: TestClusterConcurrentRW (0.40s) FAIL exit status 1 FAIL github.com/rfjakob/gocryptfs/v2/tests/cluster 0.406s
2023-06-09	tests/cluster: add TestPoCTornWriteLocked	Jakob Unterwurzacher

2023-06-09	tests/cluster: note that ext4 provides no atomicity	Jakob Unterwurzacher

2023-06-09	tests/cluster: simplify TestPoCTornWrite	Jakob Unterwurzacher
	Turns out we can get the same error with a simpler flow.
2023-06-09	tests/cluster: add TestPoCTornWrite	Jakob Unterwurzacher
	Scary. But explains why TestConcurrentCreate fails. gocryptfs/tests/cluster$ go test -run TestPoCTornWrite --- FAIL: TestPoCTornWrite (0.00s) poc_test.go:210: iteration 214: inconsistent block: d6d6d6d6d6d6d6d6d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1 FAIL
2023-06-09	tests/cluster: TestConcurrentCreate: make sure buf2 is zero'ed	Jakob Unterwurzacher

2023-06-06	tests/cluster: add TestOpenTruncate	Jakob Unterwurzacher
	This fails right now: 1 jakob@brikett:~/go/src/github.com/rfjakob/gocryptfs/tests/cluster$ go test -run TestOpenTruncate -v === RUN TestOpenTruncate cluster_test.go:235: POSIX compliance issue: non-exlusive create failed with err=file exists doWrite 2898550: corrupt header: ParseHeader: header is all-zero. Header hexdump: 000000000000000000000000000000000000 cluster_test.go:240: iteration 1: WriteAt: write /var/tmp/gocryptfs-test-parent-1026/1896094179/TestOpenTruncate.4202105280.mnt2/foo: input/output error --- FAIL: TestOpenTruncate (0.10s) FAIL exit status 1 FAIL github.com/rfjakob/gocryptfs/v2/tests/cluster 0.099s 1 jakob@brikett:~/go/src/github.com/rfjakob/gocryptfs/tests/cluster$ go test -run TestOpenTruncate -v === RUN TestOpenTruncate cluster_test.go:235: POSIX compliance issue: non-exlusive create failed with err=file exists doRead 2898565: corrupt block #0: cipher: message authentication failed ino2898565 fh9: RMW read failed: errno=5 cluster_test.go:240: iteration 8: WriteAt: write /var/tmp/gocryptfs-test-parent-1026/652691834/TestOpenTruncate.281532388.mnt1/foo: input/output error --- FAIL: TestOpenTruncate (0.09s) FAIL exit status 1 FAIL github.com/rfjakob/gocryptfs/v2/tests/cluster 0.095s
2023-06-06	tests/cluster: add TestPoCHeaderCreation	Jakob Unterwurzacher

2023-06-06	tests/cluster: move PoC tests to poc_test.go	Jakob Unterwurzacher

2023-06-06	tests/cluster: add TestConcurrentCreate	Jakob Unterwurzacher
	This exercises the byte-range locks we just added.
2023-06-05	fusefrontend: sharedstorage: use byte-range lock on file header creation	Jakob Unterwurzacher
	Multiple hosts creating the same file at the same time could have overwritten each other's file header, leading to data corruption. Fix the race by placing a byte-range lock on the file when creating the file header.
2023-05-30	tests: add cluster test	Jakob Unterwurzacher
	finds out what happens if multiple gocryptfs mounts write to one file concurrently (usually, nothing good). This use case is relevant for HPC clusters.