gocryptfs/internal/fusefrontend_reverse/ino_map.go, branch xattr_user_buffer Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=xattr_user_buffer 2017-04-01T15:19:15+00:00 fusefrontend_reverse: switch to stable inode numbers 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 fusefrontend: upgrade wlockMap to use device AND inode number 2016-11-17T19:32:19+00:00 Jakob Unterwurzacher 2016-11-17T19:32:19+00:00 urn:sha1:e04dc050126edcf7440ea5412bc74c6ad8b42e95 If there are multiple filesystems backing the gocryptfs filesystems inode numbers are not guaranteed to be unique. lint fixes 2016-10-04T21:18:33+00:00 Valient Gough 2016-10-02T04:14:18+00:00 urn:sha1:b764917cd5c1b1d61b8ce08e7af0b29793fbbb80 reverse: use dynamic inode numbers 2016-09-25T14:43:17+00:00 Jakob Unterwurzacher 2016-09-21T19:25:55+00:00 urn:sha1:d76e7aadb48e5efd6af6ad42e9146f65f8e89fb8 ...with stable mappings for hard-linked files.