Age | Commit message (Collapse) | Author |
|
|
|
Getting rid of the MD5 calculation makes calling the script
virtually free, where it took 0.2 seconds before.
|
|
This will be also used by the reverse benchmarks.
|
|
This prevents us from getting SIGINT when the user
kills the running script.
|
|
|
|
|
|
|
|
|
|
|
|
Reading partial JSON would cause a mess. Just kill the connection.
Also, stop using syscall.PathMax that is not defined on Darwin
( https://github.com/rfjakob/gocryptfs/issues/15#issuecomment-264253024 )
|
|
|
|
Both are achieved by opening the socket from main and passing
it to the ctlsock package instead of passing the path.
|
|
|
|
Also, always call build-without-openssl.bash from test.bash.
Failure was:
internal/stupidgcm/without_openssl.go:29: missing return at end of function
|
|
You used to be able to crash gocryptfs by passing "/foo"
of "foo/" to the ctlsock.
Fixes https://github.com/rfjakob/gocryptfs/issues/66
|
|
|
|
|
|
We want all panics to show up in the syslog.
|
|
$ ldd gocryptfs
not a dynamic executable
$ file gocryptfs
gocryptfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
|
|
|
|
|
|
https://github.com/rfjakob/gocryptfs/issues/64
|
|
https://github.com/rfjakob/gocryptfs/issues/64
|
|
This prevents (unlikely) symlink race attacks
|
|
We could have gotten the signal before the handler was ready,
which caused the process to wait indefinitely. This was the reason
test.bash sometimes hung.
|
|
Calling t.Fatal means that the parent test has no chance
to clean up.
|
|
Running multiple test.bash in parallel causes all kinds of
mayham.
|
|
|
|
|
|
Writing 1000 128KB blocks takes only 1 second and yielded
inconsistent results. With 2000, things look saner.
|
|
Preallocation is very slow on hdds that run btrfs. Give the
user the option to disable it. This greatly speeds up small file
operations but reduces the robustness against out-of-space errors.
Also add the option to the man page.
More info: https://github.com/rfjakob/gocryptfs/issues/63
|
|
This improves performance on hdds running ext4, and improves
streaming write performance on hdds running btrfs. Tar extract
slows down on btrfs for some reason.
See https://github.com/rfjakob/gocryptfs/issues/63
Benchmarks:
encfs v1.9.1
============
$ ./benchmark.bash -encfs /mnt/hdd-ext4
Testing EncFS at /mnt/hdd-ext4/benchmark.bash.u0g
WRITE: 131072000 bytes (131 MB, 125 MiB) copied, 1,48354 s, 88,4 MB/s
UNTAR: 20.79
LS: 3.04
RM: 6.62
$ ./benchmark.bash -encfs /mnt/hdd-btrfs
Testing EncFS at /mnt/hdd-btrfs/benchmark.bash.h40
WRITE: 131072000 bytes (131 MB, 125 MiB) copied, 1,52552 s, 85,9 MB/s
UNTAR: 24.51
LS: 2.73
RM: 5.32
gocryptfs v1.1.1-26-g4a7f8ef
============================
$ ./benchmark.bash /mnt/hdd-ext4
Testing gocryptfs at /mnt/hdd-ext4/benchmark.bash.1KG
WRITE: 131072000 bytes (131 MB, 125 MiB) copied, 1,55782 s, 84,1 MB/s
UNTAR: 22.23
LS: 1.47
RM: 4.17
$ ./benchmark.bash /mnt/hdd-btrfs
Testing gocryptfs at /mnt/hdd-btrfs/benchmark.bash.2t8
WRITE: 131072000 bytes (131 MB, 125 MiB) copied, 6,87206 s, 19,1 MB/s
UNTAR: 69.87
LS: 1.52
RM: 5.33
gocryptfs v1.1.1-32
===================
$ ./benchmark.bash /mnt/hdd-ext4
Testing gocryptfs at /mnt/hdd-ext4/benchmark.bash.Qt3
WRITE: 131072000 bytes (131 MB, 125 MiB) copied, 1,22577 s, 107 MB/s
UNTAR: 23.46
LS: 1.46
RM: 4.67
$ ./benchmark.bash /mnt/hdd-btrfs/
Testing gocryptfs at /mnt/hdd-btrfs//benchmark.bash.XVk
WRITE: 131072000 bytes (131 MB, 125 MiB) copied, 3,68735 s, 35,5 MB/s
UNTAR: 116.87
LS: 1.84
RM: 6.34
|
|
|
|
|
|
This scipt was broken for a long time and not very useful.
|
|
|
|
|
|
The primary use is testing gocryptfs, after all.
|
|
This is a regression test for the issue that was fixed by the
last commit.
|
|
This fixes the problem that a truncate can reset the file
ID without the other open FDs noticing it.
|
|
If there are multiple filesystems backing the gocryptfs filesystems
inode numbers are not guaranteed to be unique.
|
|
|
|
|
|
|
|
|
|
This could have caused spurious ENOENT errors.
That it did not cause these errors all the time is interesting
and probably because an earlier readdir would place the entry
in the cache. This masks the bug.
|
|
$ golint ./... | grep -v underscore | grep -v ALL_CAPS
internal/fusefrontend_reverse/rfs.go:52:36: exported func NewFS returns unexported type *fusefrontend_reverse.reverseFS, which can be annoying to use
internal/nametransform/raw64_go1.5.go:10:2: exported const HaveRaw64 should have comment (or a comment on this block) or be unexported
|
|
At the moment, in forward mode you can only encrypt paths
and in reverse mode you can only decrypt paths.
|
|
Paths in the root directory were encrypted to this:
foobar -> ./N9vPc0gXUY4PDSt0-muYXQ==
|
|
Old:
Nov 06 13:34:38 brikett gocryptfs[16228]: ReadDirIVAt: Read failed: EOF
Nov 06 13:34:38 brikett gocryptfs[16228]: go-fuse: can't convert error type: EOF
New:
Nov 06 14:08:43 brikett gocryptfs[17361]: ReadDirIVAt: wanted 16 bytes, got 0. Returning EINVAL.
|