Trying to build with these versions now throws this error:
# golang.org/x/sys/unix
../../../golang.org/x/sys/unix/ioctl.go:18: undefined: runtime.KeepAlive
It looks like x/sys/unix has dropped support for older Go
versions.
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.
xfstests generic/083 fills the filesystem almost completely while
running fsstress in parallel. In fsck, these would show up:
readFileID 2580: incomplete file, got 18 instead of 19 bytes
This could happen when writing the file header works, but writing
the actual data fails.
Now we kill the header again by truncating the file to zero.
If the underlying filesystem is full, writing to gocryptfs.diriv may
fail, and later fsck show this:
OpenDir "xyz": could not read gocryptfs.diriv: wanted 16 bytes, got 0
Uncovered by xfstests generic/083.
Also fixes a fd leak in the error path.
If the underlying filesystem is full, it is normal get ENOSPC here.
Log at Info level instead of Warning.
Fixes xfstests generic/015 and generic/027, which complained about
the extra output.
O_DIRECT accesses must be aligned in both offset and length. Due to our
crypto header, alignment will be off, even if userspace makes aligned
accesses. Running xfstests generic/013 on ext4 used to trigger lots of
EINVAL errors due to missing alignment. Just fall back to buffered IO.
The trezor libraries are not yet stable enough to build
gocryptfs with trezor support by default.
It does not even compile at the moment:
$ ./build.bash -tags enable_trezor
# github.com/conejoninja/tesoro/vendor/github.com/trezor/usbhid
../../conejoninja/tesoro/vendor/github.com/trezor/usbhid/hid.go:32:11: fatal error: os/threads_posix.c: No such file or directory
#include "os/threads_posix.c"
^~~~~~~~~~~~~~~~~~~~
compilation terminated.
https://github.com/conejoninja/tesoro/issues/9
If we encounter a 128KB block of zeros, try to skip to the next
data section by calling File.SeekData().
This fixes xfstests generic/285, which creates a 17TB sparse file,
and runs fsck afterwards. Without this optimization, fsck would
take ages.
"gocryptfs -fsck" will need access to helper functions,
and to get that, it will need to cast a gofuse.File to a
fusefrontend.File. Make fusefrontend.File exported to make
this work.
TrezorPayload stores 32 random bytes used for unlocking
the master key using a Trezor security module. The randomness makes sure
that a unique unlock value is used for each gocryptfs filesystem.
We are clean again.
Warnings were:
internal/fusefrontend/fs.go:443:14: should omit type string from declaration
of var cTarget; it will be inferred from the right-hand side
internal/fusefrontend/xattr.go:26:1: comment on exported method FS.GetXAttr
should be of the form "GetXAttr ..."
internal/syscallcompat/sys_common.go:9:7: exported const PATH_MAX should have
comment or be unexported
Gopkg.toml was emptied out by commit c3e12b5e68 which
seemed to work fine at the time. It turns out that, in
absence of a
branch = "master"
constraint, dep will use the last tag. We want latest
master, as this is what "go get" fetches, and hence
what Travis uses for testing.
Reading system.posix_acl_access and system.posix_acl_default
should return EOPNOTSUPP to inform user-space that we do not
support ACLs.
xftestest essientially does
chacl -l | grep "Operation not supported"
to determine if the filesystem supports ACLs, and used to
wrongly believe that gocryptfs does.
Don't dump the help text on the unsuspecting user, but
give a short error message:
$ gocryptfs -foobar
flag provided but not defined: -foobar
Invalid command line: gocryptfs -foobar. Try 'gocryptfs -help'.
For comparison: This is what cp does:
$ cp --foo
cp: unrecognized option '--foo'
Try 'cp --help' for more information.
And this what we used to do:
$ gocryptfs -foobar
flag provided but not defined: -foobar
gocryptfs v1.4.4-45-gfb772da; go-fuse v20170619-35-gb16719c; 2018-06-08 go1.10.2
Usage: gocryptfs -init|-passwd|-info [OPTIONS] CIPHERDIR
or gocryptfs [OPTIONS] CIPHERDIR MOUNTPOINT
Common Options (use -hh to show all):
-aessiv Use AES-SIV encryption (with -init)
-allow_other Allow other users to access the mount
-config Custom path to config file
-ctlsock Create control socket at location
-extpass Call external program to prompt for the password
-fg Stay in the foreground
-fusedebug Debug FUSE calls
-h, -help This short help text
-hh Long help text with all options
-init Initialize encrypted directory
-info Display information about encrypted directory
-masterkey Mount with explicit master key instead of password
-nonempty Allow mounting over non-empty directory
-nosyslog Do not redirect log messages to syslog
-passfile Read password from file
-passwd Change password
-plaintextnames Do not encrypt file names (with -init)
-q, -quiet Silence informational messages
-reverse Enable reverse mode
-ro Mount read-only
-speed Run crypto speed test
-version Print version information
-- Stop option parsing
You passed: "-foobar"
flag provided but not defined: -foobar
On Linux, where /proc exists, this makes sure that we are
executing ourselves again, and not some other copy of the
gocryptfs executable.
This usually does not matter, but mount(1) unsets $PATH
and sets argv[0] to just "gocryptfs".
mount(1) unsets PATH before calling mount.fuse. Therefore it's not set
in gocrpytfs either and daemonization fails if gocryptfs was not
executed via an absolute path.
mount.fuse handles this by leaving the execution of the helper to
/bin/sh. /bin/sh handles an empty PATH by searching a few default
locations.
This patch sets the PATH to a sane default if it's empty or unset.
