gocryptfs/internal/fusefrontend, branch v1.3Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=v1.32017-04-29T16:20:39+00:00fusefronted: drop unused file.String() function2017-04-29T16:20:39+00:00Jakob Unterwurzacher2017-04-29T16:20:39+00:00urn:sha1:b66e03486a9839d3422931f81c70ada8fc4a8b4d
This is a very old leftover.
fix golint complaints2017-04-29T12:50:58+00:00Jakob Unterwurzacher2017-04-29T12:50:58+00:00urn:sha1:edb3e19cb5543c580261052395d461fa47c7cf58forcedecode: tighten checks2017-04-23T22:25:02+00:00Jakob Unterwurzacher2017-04-23T22:25:02+00:00urn:sha1:3409ade2723d931097560fbbe35e461553c5912c
...and fix a few golint issues and print a scary warning message on mount.
Also, force the fs to ro,noexec.
Add -forcedecode2017-04-23T21:11:56+00:00danim72017-04-08T00:09:28+00:00urn:sha1:f1945c4daae65074cfca8f0ab5b97ac5a50c24a0
Force decode of encrypted files even if the integrity check fails, instead of
failing with an IO error. Warning messages are still printed to syslog if corrupted
files are encountered.
It can be useful to recover files from disks with bad sectors or other corrupted
media.
Closes https://github.com/rfjakob/gocryptfs/pull/102 .
Fix Flock build breakage2017-04-22T22:06:56+00:00Jakob Unterwurzacher2017-04-22T22:06:56+00:00urn:sha1:9777e4bf7ea2aa75ab443dc6e15c42103eb6b027
go-fuse has added a new method to the nodefs.File interface that
caused this build error:
internal/fusefrontend/file.go:75: cannot use file literal (type *file) as type nodefs.File in return argument:
*file does not implement nodefs.File (missing Flock method)
Fixes https://github.com/rfjakob/gocryptfs/issues/104 and
prevents the problem from happening again.
fusefrontend_reverse: switch to stable inode numbers2017-04-01T15:19:15+00:00Jakob Unterwurzacher2017-04-01T15:19:15+00:00urn:sha1:778c955eea1fdc16666f51f6f0a2fab0f580dbf0
The volatile inode numbers that we used before cause "find" to complain and error out.
Virtual inode numbers are derived from their parent file inode number by adding 10^19,
which is hopefully large enough no never cause problems in practice.
If the backing directory contains inode numbers higher than that, stat() on these files
will return EOVERFLOW.
Example directory lising after this change:
$ ls -i
926473 gocryptfs.conf
1000000000000926466 gocryptfs.diriv
944878 gocryptfs.longname.hmZojMqC6ns47eyVxLlH2ailKjN9bxfosi3C-FR8mjA
1000000000000944878 gocryptfs.longname.hmZojMqC6ns47eyVxLlH2ailKjN9bxfosi3C-FR8mjA.name
934408 Tdfbf02CKsTaGVYnAsSypA
fusefrontend: get rid of leftover debug output2017-03-18T15:48:28+00:00Jakob Unterwurzacher2017-03-18T15:48:28+00:00urn:sha1:cb47f65212801fbdd999674e549921d8cf23f2f2serialize_reads: add read serialization logic2017-03-18T15:18:00+00:00Jakob Unterwurzacher2017-03-18T15:01:50+00:00urn:sha1:00df0771e3dd9fba0992cbc9a7d347f25aff856a
Due to kernel readahead, we usually get multiple read requests
at the same time. These get submitted to the backing storage in
random order, which is a problem if seeking is very expensive.
Details: https://github.com/rfjakob/gocryptfs/issues/92
fusefrontend: readFileID: reject files that consist only of a header2017-03-12T20:11:02+00:00Jakob Unterwurzacher2017-03-12T20:11:02+00:00urn:sha1:14038a1644f17f50b113a05d09a2a0a3b3e973b2
A header-only file will be considered empty (this is not supposed to happen).
This makes File ID poisoning more difficult.
fusefrontend: truncateGrowFile: avoid createHeader() call2017-03-12T20:06:59+00:00Jakob Unterwurzacher2017-03-12T20:06:59+00:00urn:sha1:d36d53c9bbf1b1f1c34578d443770672528e4466
...if doWrite() can do it for us. This avoids the situation
that the file only consists of a file header when calling
doWrite.
A later patch will check for this condition and warn about it,
as with this change it should no longer occour in normal operation.