Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
Using raw64 will not work, but at least it will compile.
|
|
|
|
"-f" looks too much like "--force". The old variant is still
accepted for compatability.
|
|
|
|
Through base64.RawURLEncoding.
New command-line parameter "-raw64".
|
|
Also, use "%#v" instead of JSON for debug output.
This means we can unexport all fields.
|
|
|
|
|
|
People will search for "-o" alphabetically, so put it into the
alphabetical option list, even if it is not a real option.
|
|
|
|
The Back In Time backup tool (https://github.com/bit-team/backintime)
wants to write directly into the ciphertext dir.
This may cause the cached directory IV to become out-of-date.
Having an expiry time limits the inconstency to one second, like
attr_timeout does for the kernel getattr cache.
|
|
Simplify the code a bit.
|
|
|
|
|
|
The fix at https://github.com/hanwen/go-fuse/pull/131 has been merged.
Drop the workarounds and re-enable the tests.
|
|
It's the 1st component of GOPATH, so call it like that.
|
|
Also, standardize to "if [[ ]] ; then" style.
|
|
Calculating the block offset is easy enough, even more now
that gocryptfs-xray exists.
|
|
Running xfstests generic/075 on tmpfs often triggered a panic
for what seems to be a tmpfs bug.
Quoting from the email to lkml,
http://www.spinics.net/lists/kernel/msg2370127.html :
tmpfs seems to be incorrectly returning 0-bytes when reading from
a file that is concurrently being truncated.
|
|
Redirect stdout and stderr to /tmp/gocryptfs_paniclog.NNNNNN
instead of closing them so users have a chance to get the
backtrace on a panic.
This only applies if "-nosyslog" is NOT set. Panics will
go to terminal as usual if it is.
|