Our git version is v2+ for some time now, but go.mod
still declared v1. Hopefully making both match makes
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/%
to fix a crash reported in https://github.com/rfjakob/gocryptfs/issues/430 :
2019/10/30 17:14:16 Unknown opcode 2016
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x508d38]
This patch is only in the v2.x.x branch. Upgrade to v2, as the
old API is also supported there.
git grep hanwen/go-fuse | grep -v hanwen/go-fuse/v2
to check for forgotten references comes back clean.
...to account for unaligned reads.
I have not seen this happen in the wild because the kernel
always seems to issue 4k-aligned requests. But the cost
of the additional block in the pool is low and prevents
a buffer overrun panic when an unaligned read does happen.
We use two levels of buffers:
1) 4kiB+overhead for each ciphertext block
2) 128kiB+overhead for each FUSE write (32 ciphertext blocks)
This commit adds a sync.Pool for both levels.
The memory-efficiency for small writes could be improved,
as we now always use a 128kiB buffer.
This can happen during normal operation, and is harmless since
"fusefrontend: readFileID: reject files that consist only of a header"
causes dormant header-only files to be rewritten on the next write.
Force decode of encrypted files even if the integrity check fails, instead of
failing with an IO error. Warning messages are still printed to syslog if corrupted
files are encountered.
It can be useful to recover files from disks with bad sectors or other corrupted
Closes https://github.com/rfjakob/gocryptfs/pull/102 .
Running xfstests generic/075 on tmpfs often triggered a panic
for what seems to be a tmpfs bug.
Quoting from the email to lkml,
tmpfs seems to be incorrectly returning 0-bytes when reading from
a file that is concurrently being truncated.