gocryptfs/internal/openfiletable, branch v2.0-beta1 Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v2.0-beta1 2020-04-13T12:54:04+00:00 inomap: split into separate package 2020-04-13T12:54:04+00:00 Jakob Unterwurzacher 2020-04-12T15:15:03+00:00 urn:sha1:488111ce390218806fca933b89279b766f7ff49c inomap will also be used by fusefrontend_reverse in the future. Split if off openfiletable to make it independent. openfiletable: add inummap 2019-11-16T20:35:26+00:00 Jakob Unterwurzacher 2019-11-16T20:35:26+00:00 urn:sha1:e5d5ab397384001566d573a13a142ed1bc2bc2aa Generates unique inode numbers for files on different devices. https://github.com/rfjakob/gocryptfs/issues/435 Add option for autounmount 2018-10-11T18:16:45+00:00 Jesse Dunietz 2018-10-06T19:49:33+00:00 urn:sha1:87d3ed9187cb9caccaa8df0769d4cb722cc5bd00 Even though filesystem notifications aren't implemented for FUSE, I decided to try my hand at implementing the autounmount feature (#128). I based it on the EncFS autounmount code, which records filesystem accesses and checks every X seconds whether it's idled long enough to unmount. I've tested the feature locally, but I haven't added any tests for this flag. I also haven't worked with Go before. So please let me know if there's anything that should be done differently. One particular concern: I worked from the assumption that the open files table is unique per-filesystem. If that's not true, I'll need to add an open file count and associated lock to the Filesystem type instead. https://github.com/rfjakob/gocryptfs/pull/265 fusefronted: disallow writes running concurrently with reads 2018-07-22T20:29:22+00:00 Jakob Unterwurzacher 2018-07-22T20:29:22+00:00 urn: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. openfiletable: rename WriteLock to ContentLock 2017-05-01T19:57:18+00:00 Jakob Unterwurzacher 2017-05-01T19:57:18+00:00 urn:sha1:fb3cc6ea407b83e4e1acf4e1a80e3b7d09c5b1db ...and IDLock to HeaderLock. This matches what the locks actually protect. fusefronted, openfiletable: move the open file table to its own package 2017-05-01T15:26:50+00:00 Jakob Unterwurzacher 2017-05-01T15:26:50+00:00 urn:sha1:514f515dd7196e26ca8df6886ac4a34e928e50dd The open file table code needs some room to grow for the upcoming FD multiplexing implementation.