gocryptfs/internal/fusefrontend, branch v1.6Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=v1.62018-08-15T15:25:22+00:00fusefrontend: truncateGrowFile: pass zeroPad error to caller2018-08-15T15:25:22+00:00Jakob Unterwurzacher2018-08-15T15:14:24+00:00urn:sha1:dbd400d930ccd790c2918f6382c0efaeb353c282
Errors from zeroPad were ignored until now, as discovered
using xfstests generic/083.
reverse mode: add --exclude option2018-08-11T21:26:49+00:00Jakob Unterwurzacher2018-08-11T21:26:49+00:00urn:sha1:ec2fdc19cf9358ae7ba09c528a5807b6b0760f9b
https://github.com/rfjakob/gocryptfs/issues/235
fusefronted: disallow writes running concurrently with reads2018-07-22T20:29:22+00:00Jakob Unterwurzacher2018-07-22T20:29:22+00:00urn:sha1:f316f1b2df47dca651174e574ab072f6b46c0b01
As uncovered by xfstests generic/465, concurrent reads and writes
could lead to this,
doRead 3015532: corrupt block #1039: stupidgcm: message authentication failed,
as the read could pick up a block that has not yet been completely written -
write() is not atomic!
Now writes take ContentLock exclusively, while reads take it shared,
meaning that multiple reads can run in parallel with each other, but
not with a write.
This also simplifies the file header locking.
fusefrontend: doWrite: delete file header if first write fails2018-07-15T13:12:55+00:00Jakob Unterwurzacher2018-07-15T12:14:12+00:00urn:sha1:c70df522d2a78f3152fa61511bed9fafa7c495a3
xfstests generic/083 fills the filesystem almost completely while
running fsstress in parallel. In fsck, these would show up:
readFileID 2580: incomplete file, got 18 instead of 19 bytes
This could happen when writing the file header works, but writing
the actual data fails.
Now we kill the header again by truncating the file to zero.
fusefrontend: doWrite: no need to take HeaderLock.RLock()2018-07-15T10:40:23+00:00Jakob Unterwurzacher2018-07-15T10:40:23+00:00urn:sha1:55bb22bad6c196f363ad27fbedad4f5360c4879f
Other writers are blocked by ContentLock already.
fusefrontend: log prealloc failures at Info level2018-07-14T13:18:27+00:00Jakob Unterwurzacher2018-07-14T13:18:27+00:00urn:sha1:95b93db35f451dbaef49ae53c9b69e32dc10e14a
If the underlying filesystem is full, it is normal get ENOSPC here.
Log at Info level instead of Warning.
Fixes xfstests generic/015 and generic/027, which complained about
the extra output.
macos: fix O_DIRECT build failure2018-07-04T07:04:00+00:00Jakob Unterwurzacher2018-07-04T07:04:00+00:00urn:sha1:53f7e1a0f02c44d19b8cda178daebe0aa466f352
O_DIRECT has no direct equivalent on MacOS
(check out https://github.com/libuv/libuv/issues/1600 for details).
Just define it to zero there.
fusefrontend: disallow O_DIRECT and fall back to buffered IO2018-07-02T21:54:37+00:00Jakob Unterwurzacher2018-07-02T21:54:37+00:00urn:sha1:893e41149ed353f355047003b89eeff456990e76
O_DIRECT accesses must be aligned in both offset and length. Due to our
crypto header, alignment will be off, even if userspace makes aligned
accesses. Running xfstests generic/013 on ext4 used to trigger lots of
EINVAL errors due to missing alignment. Just fall back to buffered IO.
fusefronted: downgrade fallocate message severity2018-07-02T21:03:43+00:00Jakob Unterwurzacher2018-07-02T21:03:43+00:00urn:sha1:c51fc9e07d287a95ce70b9fd8de8ea09a1d934c2
The message causes output mismatches in xfstests generic/112.
Downgrade the severity to Info so it gets disabled when using "-q".
Fix golint warnings2018-07-01T20:00:06+00:00Jakob Unterwurzacher2018-07-01T20:00:06+00:00urn:sha1:01a078e7c0d75b0564282fc7613944be858a522f