Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.4.2 2017-10-22T16:13:08+00:00 2017-10-22T16:13:08+00:00 Jakob Unterwurzacher 2017-10-22T16:13:08+00:00 urn:sha1:34547a6c390bfadf2342df1676f6e5ddfa4876af This could lead to test failures like this: --- FAIL: TestGetdents (0.02s) getdents_test.go:57: len(getdentsEntries)=362, len(readdirEntries)=360 FAIL 2017-10-21T15:43:21+00:00 Jakob Unterwurzacher 2017-10-21T15:43:21+00:00 urn:sha1:268e0484e24c3ecf9ec8df189a18cbbf36f81d1a We cannot return less data than requested to the kernel! From https://libfuse.github.io/doxygen/structfuse__operations.html: Read should return exactly the number of bytes requested except on EOF or error, otherwise the rest of the data will be substituted with zeroes. Reverts commit 3009ec9852316c3c696f77f476390ab5a6d8d6d7 minus the formatting improvements we want to keep. Fixes https://github.com/rfjakob/gocryptfs/issues/147 Reopens https://github.com/rfjakob/gocryptfs/issues/145 2017-10-19T07:23:10+00:00 Jakob Unterwurzacher 2017-10-19T07:23:10+00:00 urn:sha1:29445c976d200f6e734eae56d9665fd4098f0a43 ...to account for unaligned reads. I have not seen this happen in the wild because the kernel always seems to issue 4k-aligned requests. But the cost of the additional block in the pool is low and prevents a buffer overrun panic when an unaligned read does happen. 2017-10-17T19:48:29+00:00 Jakob Unterwurzacher 2017-10-17T19:47:32+00:00 urn:sha1:3009ec9852316c3c696f77f476390ab5a6d8d6d7 Our byte cache pools are sized acc. to MAX_KERNEL_WRITE, but the running kernel may have a higher limit set. Clamp to what we can handle. Fixes a panic on a Synology NAS reported at https://github.com/rfjakob/gocryptfs/issues/145 2017-10-01T11:50:25+00:00 Jakob Unterwurzacher 2017-10-01T11:50:25+00:00 urn:sha1:4da245c69d7994efec75e1deaef56a03020d39db A file with a name of exactly 176 bytes length caused this error: ls: cannot access ./tmp/dsg/sXSGJLTuZuW1FarwIkJs0w/b6mGjdxIRpaeanTo0rbh0A/QjMRrQZC_4WLhmHI1UOBcA/gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY: No such file or directory ls: cannot access ./tmp/dsg/sXSGJLTuZuW1FarwIkJs0w/b6mGjdxIRpaeanTo0rbh0A/QjMRrQZC_4WLhmHI1UOBcA/gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY.name: No such file or directory -????????? ? ? ? ? ? gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY -????????? ? ? ? ? ? gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY.name Root cause was a wrong shortNameMax constant that failed to account for the obligatory padding byte. Fix the constant and also expand the TestLongnameStat test case to test ALL file name lengths from 1-255 bytes. Fixes https://github.com/rfjakob/gocryptfs/issues/143 . 2017-09-17T09:42:46+00:00 Jakob Unterwurzacher 2017-09-17T09:42:46+00:00 urn:sha1:0072a96f20c99bf386d8e3f63741def5a3945018 2017-09-17T09:21:48+00:00 Jakob Unterwurzacher 2017-09-17T09:21:48+00:00 urn:sha1:885fdcabdacb2d53829e7f96f4c600df0a3e282d The encrypt and decrypt path both had a copy that were equivalent but ordered differently, which was confusing. Consolidate it in a new dedicated function. 2017-09-17T08:59:04+00:00 Jakob Unterwurzacher 2017-09-17T08:59:04+00:00 urn:sha1:4bd2c6736afbe20d6aa7d94758082d8c8752af4b Using firstBlockNo as the counter is confusing, create a copy named "blockNo" and use that. 2017-09-05T20:47:15+00:00 Jakob Unterwurzacher 2017-09-05T20:47:15+00:00 urn:sha1:604b0779d47d39fc5390a67167a8090748843cc1 MacOS sprinkles .DS_Store files everywhere. This is hard to avoid for users, so handle it transparently in Rmdir(). Mitigates https://github.com/rfjakob/gocryptfs/issues/140 2017-09-05T20:10:08+00:00 Jakob Unterwurzacher 2017-09-05T20:08:59+00:00 urn:sha1:6f3b65d924d8ab0827516ee274935b2c18979e10 Handle the errors first so that the normal code path is not indented. This should not cause any behavoir changes.