An Open() a fifo blocks until it is opened for writing.
This meant that xattr operations on FIFOs would block.
Pass O_NONBLOCK to fix that, and add a test.
Failure was:
+ GOOS=darwin
+ GOARCH=amd64
+ go build -tags without_openssl
# github.com/rfjakob/gocryptfs/internal/fusefrontend
internal/fusefrontend/fs_dir.go:159:60: cannot use origMode | 448 (type uint16) as type uint32 in argument to syscallcompat.Fchmodat
internal/fusefrontend/fs_dir.go:170:33: cannot use origMode (type uint16) as type uint32 in argument to syscallcompat.Fchmodat
Use openBackingDir() and Fstatat().
High performance impact, though part of it should be
mitigated by adding DirIV caching to the new code paths.
$ ./benchmark.bash
Testing gocryptfs at /tmp/benchmark.bash.Eou: gocryptfs v1.6-37-ge3914b3-dirty; go-fuse v20170619-66-g6df8ddc; 2018-10-14 go1.11
WRITE: 262144000 bytes (262 MB, 250 MiB) copied, 1.2289 s, 213 MB/s
READ: 262144000 bytes (262 MB, 250 MiB) copied, 1.02616 s, 255 MB/s
UNTAR: 24.490
MD5: 13.120
LS: 3.368
RM: 9.232
The directory was already created, so return success even if Fchownat fails.
The same error handling is already used if fs.args.PlaintextNames is false.
This ensures that ./build.bash still works when the LDFLAGS environment
variable contains multiple options, e.g., LDFLAGS="-lpthread -lm". The
correct way of passing multiple options is discussed here:
https://github.com/golang/go/issues/6234
For some unknown reason, the method only works when -extldflags is the
last argument - is this a bug in Go?
Old XFS filesystems always return DT_UNKNOWN. Downgrade the message
to "info" level if we are on XFS.
Using the "warning" level means that users on old XFS filesystems
cannot run the test suite as it intentionally aborts on any
warnings.
Fixes https://github.com/rfjakob/gocryptfs/issues/267
The hardcoded full paths were introduced to handle the
case of an empty PATH environment variable. However,
since commit 10212d791a we set PATH to a default
value if empty. The hardcoded paths are no longer neccessary,
and cause problems on some distros:
User voobscout on
https://github.com/rfjakob/gocryptfs/issues/225#issuecomment-438682034 :
just to chime in - please don't hardcode paths, for example I'm on
NixOS and logger lives in /run/current-system/sw/bin/logger
Drop the hardcoded paths.
When gocryptfs was started on a terminal and later
daemonized, the color codes stayed active in the syslog
output.
The codes are not visible in "journalctl -f", which is why
I have not noticed it yet, but they do show up in normal
syslog as the usual "#033[33m" crap.
The messages would still be collected via gocryptfs-logger,
but let's do it right.
Before:
Oct 17 21:58:12 brikett gocryptfs[9926]: testing info
Oct 17 21:58:12 brikett gocryptfs[9926]: testing warn
Oct 17 21:58:12 brikett gocryptfs-9926-logger[9935]: testing fatal
After:
Oct 17 22:00:53 brikett gocryptfs[10314]: testing info
Oct 17 22:00:53 brikett gocryptfs[10314]: testing warn
Oct 17 22:00:53 brikett gocryptfs[10314]: testing fatal
