$ ./contrib/atomicrename/atomicrename -h
atomicrename creates 100 "src" files in the current directory, renames
them in random order over a single "dst" file while reading the "dst"
file concurrently in a loop.
Progress and errors are reported as they occour in addition to a summary
printed at the end. cifs and fuse filesystems are known to fail, local
filesystems and nfs seem ok.
See https://github.com/hanwen/go-fuse/issues/398 for background info.
If you do something like this,
go mod edit -replace github.com/hanwen/go-fuse/v2=/home/jakob/go/src/github.com/hanwen/go-fuse
the version string of the resulting binary should reflect that.
Before:
gocryptfs v1.8.0-135-g352b547-dirty.gofuse_v2api; go-fuse v2.0.4-0.20200908172753-0b6cbc515082; 2020-10-03 go1.15.2 linux/amd64
After:
gocryptfs v1.8.0-135-g352b547-dirty.gofuse_v2api; go-fuse v2.0.4-0.20200908172753-0b6cbc515082 => /home/jakob/go/src/github.com/hanwen/go-fuse; 2020-10-03 go1.15.2 linux/amd64
We need
fd7328faf9
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.
Running
git grep hanwen/go-fuse | grep -v hanwen/go-fuse/v2
to check for forgotten references comes back clean.
The case of a git repo without any tags used to fail
with:
fatal: No names found, cannot describe anything.
Now we continue, using "[no_tags_found]" as the
version string.
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?
As noticed by @riking, the logic in the bash script will break
when Go 1 version numbers reach double-digits.
Instead, use a build tag "!go1.5" to cause a syntax error:
$ /opt/go1.4.3/bin/go build
can't load package: package github.com/rfjakob/gocryptfs:
go1.4.go:5:1: expected 'package', found 'STRING' "You need Go 1.5 or higher to compile gocryptfs!"
Fixes https://github.com/rfjakob/gocryptfs/issues/133
As v0.4 introduced ext4-style feature flags, the on-disk format version
is unlinkely to change. Drop it from the version output to reduce
clutter. Use "gocryptfs -version -debug" to see it.
Add the Go version string because only Go 1.6 and newer have an optimized
AES-GCM implementation. This will help users to understand the performance
of their build.
This used to fail in an ugly way:
$ ./build.bash
./build.bash: line 13: go: command not found
./build.bash: line 15: [: too many arguments
./build.bash: line 20: go: command not found
Jakob Unterwurzacher