We used to prefer openssl in this situation, which
used to make sense, but now Go gained an optimized
assembly implementation for aes-gcm on arm64 with
aes instructions:
root@q1:~/go/src/github.com/rfjakob/gocryptfs# ./gocryptfs -speed
gocryptfs v1.7.1-46-g73436d9; go-fuse v1.0.1-0.20190319092520-161a16484456; 2020-04-13 go1.14.2 linux/arm64
AES-GCM-256-OpenSSL 212.30 MB/s (selected in auto mode)
AES-GCM-256-Go 452.30 MB/s
AES-SIV-512-Go 100.25 MB/s
XChaCha20-Poly1305-Go 137.35 MB/s
https://github.com/rfjakob/gocryptfs/issues/452
Output now looks like this
$ gocryptfs -speed
gocryptfs v1.7.1-38-gbe3b9df-dirty; go-fuse v2.0.2-57-gd1cfa17; 2020-04-13 go1.13.6 linux/amd64
AES-GCM-256-OpenSSL 607.90 MB/s
AES-GCM-256-Go 920.75 MB/s (selected in auto mode)
AES-SIV-512-Go 169.85 MB/s
XChaCha20-Poly1305-Go 794.30 MB/s
and has go version and arch information, which is important
when comparing results.
From https://github.com/golang/go/wiki/GoArm :
In cross compilation situations, it is recommended
that you always set an appropriate GOARM value
along with GOARCH.
The value seems to default to GOARM=5 if not set
during cross-compilation.
We used to restrict setting xattrs to the "user."
namespace. I don't see a real reason for this
anymore, and it causes trouble for users who are using
acls.
Tests will be added in the next commit.
https://github.com/rfjakob/gocryptfs/issues/453
Now that I have discovered golang.org/x/sys/cpu and that Go
versions below 1.6 are uncommon, there was not much useful
code left in prefer_openssl.
Merge the remains into stupidgcm.
Use exec.LookPath() to find fusermount in the user's PATH
first. Fall back to /bin/fusermount for the case that PATH
is not set, like go-fuse does.
Fixes https://github.com/rfjakob/gocryptfs/issues/448
fusermount3 (i.e. fusermount from libfuse 3.x) has dropped
the `nonempty` option.
Detect fusermount3 and don't add `nonempty` in this case.
Fixes https://github.com/rfjakob/gocryptfs/pull/440
Move the statusTxtContent to fix this confusing error
when running `go get github.com/rfjakob/gocryptfs/...`:
$ go get github.com/rfjakob/gocryptfs/...
# github.com/rfjakob/gocryptfs/tests/example_filesystems
tests/example_filesystems/example_test_helpers.go:22:16: undefined: statusTxtContent
tests/example_filesystems/example_test_helpers.go:75:16: undefined: statusTxtContent
Feedback received during the recent Go user group. If you haven't
used FUSE before, you don't know how to unmount, and it was not
described in the man page!
As for the options, there are many, and new users are intimidated
by it. State clearly that defaults are fine.
Error from Travis CI was:
+GOOS=darwin
+GOARCH=amd64
+go build -tags without_openssl
# github.com/rfjakob/gocryptfs/internal/fusefrontend
internal/fusefrontend/fs.go:88:45: cannot use st.Dev (type int32) as type uint64 in argument to openfiletable.NewInumMap
Add uint64 to fix it.
The comment is outdated, at this point, we should
really not get any errors from ReadDirIVAt.
The change is best seen when running the fsck tests. Before:
fsck: error opening dir "missing_diriv": 2=no such file or directory
After:
OpenDir "K2m0E6qzIfoLkVZJanoUiQ": could not read gocryptfs.diriv: no such file or directory
fsck: error opening dir "missing_diriv": 5=input/output error
See https://github.com/rfjakob/gocryptfs/issues/403 , where
the extra info would have been helpful.
This was meant as a way to inform the user that
something is very wrong, however, users are hitting
the condition on MacOS due to ".DS_Store" files, and
also on NFS due to ".nfsXXX" files.
Drop the whole thing as it seems to cause more pain
than gain.
Fixes https://github.com/rfjakob/gocryptfs/issues/431
Jakob Unterwurzacher