gocryptfs/tests/defaults, branch v1.5Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=v1.52018-05-17T21:14:33+00:00tests: add "mv broken symlink" test2018-05-17T21:14:33+00:00Jakob Unterwurzacher2018-05-17T21:14:33+00:00urn:sha1:44caf21debd445623fb481827fae6fc8a5eb911d
This currently fails because we do not use llistxattr
yet.
xattr: return EOPNOTSUPP for unsupported attributes2018-05-15T21:00:47+00:00Jakob Unterwurzacher2018-05-15T21:00:47+00:00urn:sha1:7b0068180772b9dd7e0b00ca9e1b0f3ce39c9c23
mv is unhappy when we return EPERM when it tries to set
system.posix_acl_access:
mv: preserving permissions for ‘b/x’: Operation not permitted
Now we return EOPNOTSUPP like tmpfs does and mv seems happy.
fsck: clean up log output2018-04-02T16:32:30+00:00Jakob Unterwurzacher2018-04-02T16:32:30+00:00urn:sha1:b6c8960b01f9e5366814b0dada57a0b1e6a031d9
Make sure we get only 1 warning output per
problem.
Also, add new corruption types to broken_fs_v1.4.
tests: fix a few fd leaks2018-03-05T21:00:59+00:00Jakob Unterwurzacher2018-03-05T20:56:30+00:00urn:sha1:3064d72b9774029ab89daea8a7fccfe181c3cae0
We relied on the finalizer to close a few fds.
For some reason, this did not cause problems on Linux,
but on MacOS, it causes unmount failures:
umount(/private/tmp/gocryptfs-test-parent/194654785/default-plain): Resource busy -- try 'diskutil unmount'
tests: add diriv cache race test2017-08-10T19:01:19+00:00Jakob Unterwurzacher2017-08-10T18:55:45+00:00urn:sha1:f59479736bed49411bda3368f419d6605f1faa78
Passes.
fusefronted: enable writing to write-only files2017-07-11T21:19:58+00:00Jakob Unterwurzacher2017-07-11T21:19:58+00:00urn:sha1:3062de6187990f9b4f669ecd9dffdd48ee0d778f
Due to RMW, we always need read permissions on the backing file. This is a
problem if the file permissions do not allow reading (i.e. 0200 permissions).
This patch works around that problem by chmod'ing the file, obtaining a fd,
and chmod'ing it back.
Test included.
Issue reported at: https://github.com/rfjakob/gocryptfs/issues/125
fusefrontend: implement path decryption via ctlsock2017-05-07T19:01:39+00:00Jakob Unterwurzacher2017-05-07T19:01:39+00:00urn:sha1:ad7942f434fea567f24458e67a0919291b5ec8dd
Closes https://github.com/rfjakob/gocryptfs/issues/84 .
tests: add TestXfs1242017-05-01T16:44:03+00:00Jakob Unterwurzacher2017-05-01T16:36:25+00:00urn:sha1:9768376bd1961a5aa0fbf7f08de0601322664fc3
This test reproduces the problem xfstests generic/124 uncovered.
The warning itself is harmless, but we should either (1) add locking
so that this cannot happen anymore or (2) drop the warning.
Currently fails:
$ go test -v
=== RUN Test1980Tar
--- PASS: Test1980Tar (0.00s)
=== RUN TestCtlSock
--- PASS: TestCtlSock (0.10s)
=== RUN TestOpenTruncateRead
--- PASS: TestOpenTruncateRead (0.00s)
=== RUN TestWORead
--- PASS: TestWORead (0.00s)
=== RUN TestXfs124
cipherSize 18 == header size: interrupted write?
-wpanic turns this warning into a panic: cipherSize 18 == header size: interrupted write?
fusefrontend: drop writeOnly flag2017-05-01T15:49:37+00:00Jakob Unterwurzacher2017-05-01T15:49:37+00:00urn:sha1:9ab11aa4d775f7c1242e8b044cc2f8957cc2c784
We do not have to track the writeOnly status because the kernel
will not forward read requests on a write-only FD to us anyway.
I have verified this behavoir manually on a 4.10.8 kernel and also
added a testcase.
tests: ctlsock: check warning for non-canonical paths2017-02-12T11:22:25+00:00Jakob Unterwurzacher2017-02-12T11:22:25+00:00urn:sha1:357307cbcfaafb2b22f01e780d717df1a3f8eb1b