gocryptfs - Mirror of gocryptfs source code on Github

Age	Commit message (Collapse)	Author
2025-05-06	Switch to the new atomic Uint64.Add api	Jakob Unterwurzacher
	The new api guarantees that the value is aligned, preventing stuff like this on 32 bit platforms: goroutine 26 [running]: internal/runtime/atomic.panicUnaligned() /usr/lib/go-1.24/src/internal/runtime/atomic/unaligned.go:8 +0x24 internal/runtime/atomic.Xadd64(0x2496c74, 0x1) /usr/lib/go-1.24/src/internal/runtime/atomic/atomic_arm.s:318 +0x14 github.com/rfjakob/gocryptfs/internal/inomap.(*InoMap).NextSpillIno(0x2496c60) Fixes https://github.com/rfjakob/gocryptfs/issues/912
2021-08-23	go mod: declare module version v2	Jakob Unterwurzacher
	Our git version is v2+ for some time now, but go.mod still declared v1. Hopefully making both match makes https://pkg.go.dev/github.com/rfjakob/gocryptfs/v2 work. All the import paths have been fixed like this: find . -name \*.go \| xargs sed -i s%github.com/rfjakob/gocryptfs/%github.com/rfjakob/gocryptfs/v2/%
2020-04-13	inomap: split into separate package	Jakob Unterwurzacher
	inomap will also be used by fusefrontend_reverse in the future. Split if off openfiletable to make it independent.
2018-10-11	Add option for autounmount	Jesse Dunietz
	Even though filesystem notifications aren't implemented for FUSE, I decided to try my hand at implementing the autounmount feature (#128). I based it on the EncFS autounmount code, which records filesystem accesses and checks every X seconds whether it's idled long enough to unmount. I've tested the feature locally, but I haven't added any tests for this flag. I also haven't worked with Go before. So please let me know if there's anything that should be done differently. One particular concern: I worked from the assumption that the open files table is unique per-filesystem. If that's not true, I'll need to add an open file count and associated lock to the Filesystem type instead. https://github.com/rfjakob/gocryptfs/pull/265
2018-07-22	fusefronted: disallow writes running concurrently with reads	Jakob Unterwurzacher
	As uncovered by xfstests generic/465, concurrent reads and writes could lead to this, doRead 3015532: corrupt block #1039: stupidgcm: message authentication failed, as the read could pick up a block that has not yet been completely written - write() is not atomic! Now writes take ContentLock exclusively, while reads take it shared, meaning that multiple reads can run in parallel with each other, but not with a write. This also simplifies the file header locking.
2017-05-01	openfiletable: rename WriteLock to ContentLock	Jakob Unterwurzacher
	...and IDLock to HeaderLock. This matches what the locks actually protect.
2017-05-01	fusefronted, openfiletable: move the open file table to its own package	Jakob Unterwurzacher
	The open file table code needs some room to grow for the upcoming FD multiplexing implementation.