Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.3 2017-04-29T12:50:58+00:00 2017-04-29T12:50:58+00:00 Jakob Unterwurzacher 2017-04-29T12:50:58+00:00 urn:sha1:edb3e19cb5543c580261052395d461fa47c7cf58 2017-04-23T21:11:56+00:00 danim7 2017-04-08T00:09:28+00:00 urn: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 . 2017-04-01T15:19:15+00:00 Jakob Unterwurzacher 2017-04-01T15:19:15+00:00 urn: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 2017-04-01T15:05:55+00:00 Jakob Unterwurzacher 2017-04-01T15:05:55+00:00 urn:sha1:e87aebb835b91ba66f288030ee3510df42b860a9 This has long been replaced by virtualFile.GetAttr(). 2017-04-01T13:49:53+00:00 Jakob Unterwurzacher 2017-04-01T13:49:53+00:00 urn:sha1:acb73ca4363a8fbf3e0be1907a9b26689d879d73 The fmt.Printfs output would end up in the paniclog. 2017-04-01T12:17:54+00:00 Jakob Unterwurzacher 2017-04-01T12:17:54+00:00 urn:sha1:3cd18f288f487f0dfc8bd8de1288ed3b92cc5ca5 ...and improve and comment variable naming in findLongnameParent. No semantic changes. 2017-03-28T20:58:03+00:00 danim7 2017-03-27T20:47:45+00:00 urn:sha1:fb1b8ced3843a449f2a85d4ee0a9d426192d82fa This PR addresses the Issue #95, about "Confusing file owner for longname files in reverse mode". It affects only the reverse mode, and introduces two modifications: 1) The "gocryptfs.longname.XXXX.name" files are assigned the owner and group of the underlying plaintext file. Therefore it is consistent with the file "gocryptfs.longname.XXXX" that has the encrypted contents of the plaintext file. 2) The two virtual files mentioned above are given -r--r--r-- permissions. This is consistent with the behavior described in function Access in internal/fusefrontend_reverse/rfs.go where all virtual files are always readable. Behavior also observed in point c) in #95 . Issue #95 URL: https://github.com/rfjakob/gocryptfs/issues/95 Pull request URL: https://github.com/rfjakob/gocryptfs/pull/97 2017-03-07T19:46:58+00:00 M. Vefa Bicakci 2017-03-07T09:09:09+00:00 urn:sha1:d48ccb3ddab71773a991b8f1b062901ff5b435b0 Prior to this commit, gocryptfs's reverse mode did not report correct directory entry sizes for symbolic links, where the dentry size needs to be the same as the length of a string containing the target path. This commit corrects this issue and adds a test case to verify the correctness of the implementation. This issue was discovered during the use of a strict file copying program on a reverse-mounted gocryptfs file system. 2017-03-05T21:59:25+00:00 Jakob Unterwurzacher 2017-03-05T21:59:25+00:00 urn:sha1:445b5019e3f5a74409ca66c166cc1c3ccdd3dce7 The symlink functions incorrectly hardcoded the padded base64 variant. 2017-03-05T21:25:41+00:00 Jakob Unterwurzacher 2017-03-05T21:25:41+00:00 urn:sha1:5b54577d2ec553055c06e05841f626c10368c6b6 HashLongName() incorrectly hardcoded the call to base64.URLEncoding.