This field is added for the convenience of users and
may help them to identify which gocryptfs version
they need to mount a filesystem.
The same information is essentially contained in FeatureFlags,
but this is more difficult to decode for humans.
It is completely ignored programmatically (also by older gocryptfs
versions).
Just presenting an empty directory means that the user does not know
that things went wrong unless he checks the syslog or tries to delete
the directory.
It would be nice to report the error even if only some files were
invalid. However, go-fuse does not allow returning the valid
directory entries AND an error.
gocryptfs v0.9 introduced long file names, so lets add an
example filesystem that has that feature flag set.
Operations on long file names are tested in the regular integration
tests as well.
... but only if the relative path does not start with "..".
Makes the message easier to grasp. Example:
$ gocryptfs -init -scryptn=10 v0.9
[...]
The filesystem has been created successfully.
Before:
You can now mount it using: gocryptfs /home/jakob/src/github.com/rfjakob/gocryptfs/integration_tests/example_filesystems/v0.9 MOUNTPOINT
After:
You can now mount it using: gocryptfs v0.9 MOUNTPOINT
... with the "released" boolean.
For some reason, the "f.fd.Fd() < 0" check did not work reliably,
leading to nil pointer panics on the following wlock.lock().
The problem was discovered during fsstress testing and is unlikely
to happen in normal operations.
With this change, we passed 1700+ fsstress iterations.
Send fsstress (which ignores Ctrl-C) into the background
so the shell gets the signal. Manually kill fsstress in the
cleanup handler.
Also, use the build.bash script for gocryptfs.
Also, convert extractloop.bash to using md5sum instead of diff -ur
so the user does not have to keep an extracted kernel tree around.
And print the iteration time.
Paths in statfs() calls were not encrypted resulting in
an Function not implemented error, when the unencrypted
path didn't exist in the underlying (encrypted)
filesystem.
$ df plain/existingdir
df: ‘plain/existingdir’: Function not implemented
Go GCM is faster than OpenSSL if the CPU has AES instructions
and you are running Go 1.6+.
The "-openssl" option now defaults to "auto".
"gocryptfs -debug -version" displays the result of the autodetection.
See https://github.com/rfjakob/gocryptfs/issues/23 for details and
benchmarks.
Commit 730291feab properly freed wlock when the file descriptor is
closed. However, concurrently running Write and Truncates may
still want to lock it. Check if the fd has been closed first.
In general, OpenSSL is only threadsafe if you provide a locking function
through CRYPTO_set_locking_callback. However, the GCM operations that
stupidgcm uses never call that function.
To guard against that ever changing, set a dummy locking callback
that crashes the app.
Quoting from the patch:
We compare against Go's built-in GCM implementation. Since stupidgcm only
supports 128-bit IVs and Go only supports that from 1.5 onward, we cannot
run these tests on older Go versions.
This fixes the test failures on Travis CI.
Quoting from 07a4ff79d2
/* Set expected tag value. A restriction in OpenSSL 1.0.1c and earlier
* required the tag before any AAD or ciphertext */
...complete with tests and benchmark.
This will allow us to get rid of the dependency to spacemonkeygo/openssl
that causes problems on Arch Linux
( https://github.com/rfjakob/gocryptfs/issues/21 )
