gocryptfs/internal/fusefrontend_reverse/root_node.go, branch LockSharedStorage_rebase2Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=LockSharedStorage_rebase22026-07-12T18:39:59+00:00reverse: hide custom -config file located inside CIPHERDIR2026-07-12T18:39:59+00:00maximilize2026-06-25T22:23:30+00:00urn:sha1:3ac282047ff36affb86f260b54ff50653007fdee
In reverse mode, a custom config file passed via -config that lives inside
CIPHERDIR was presented as an ordinary encrypted file in the encrypted view,
which is useless and confusing. By default the config is mapped to a virtual
gocryptfs.conf, but ConfigCustom skips that mapping, so an in-CIPHERDIR custom
config was neither mapped nor hidden.
Plumb the config path into the reverse RootNode and treat a custom config file
located inside CIPHERDIR as excluded in isExcludedPlain, hiding it from both
readdir and lookup. Also document the -config reverse-mode behaviour in
MANPAGE.md and add a regression test.
Fixes #1009
Fix issue with reverse mode and excluded virtual files2026-02-10T20:38:04+00:00m4rc0d12026-02-09T17:39:55+00:00urn:sha1:5f5c34ac78cb9d1765ce9cabe87420c32f9d867e
This fixes #686. Now the `gocryptfs.longname.*.name` are present and readable in the
reverse mount, regardless of the complexity of the exclusion patterns.
The main issue was a `cPath` instead of `dPath` for the exclude check in
`fusefrontend_reverse/node_helpers.go`. Also added a check to avoid the exclusion of
`gocryptfs.conf` in the root directory.
The test run results are in line with the main branch.
Fixes https://github.com/rfjakob/gocryptfs/issues/686
Xattrs support in reverse mode2025-11-22T20:24:20+00:00Aleksey Vasenev2024-11-17T20:14:36+00:00urn:sha1:ed1c5e4a9f5ce1921f3ec03b32e591ce828ec5b9
Fixes https://github.com/rfjakob/gocryptfs/issues/827
Switch to the new atomic Uint64.Add api2025-05-06T07:11:49+00:00Jakob Unterwurzacher2025-05-06T07:11:49+00:00urn:sha1:9b6e47fc0a2ed65d462424152a13f995a8d7dd9a
The new api guarantees that the value is aligned, preventing
stuff like this on 32 bit platforms:
goroutine 26 [running]:
internal/runtime/atomic.panicUnaligned()
/usr/lib/go-1.24/src/internal/runtime/atomic/unaligned.go:8 +0x24
internal/runtime/atomic.Xadd64(0x2496c74, 0x1)
/usr/lib/go-1.24/src/internal/runtime/atomic/atomic_arm.s:318 +0x14
github.com/rfjakob/gocryptfs/internal/inomap.(*InoMap).NextSpillIno(0x2496c60)
Fixes https://github.com/rfjakob/gocryptfs/issues/912
fusefrontend_reverse: import go-gitignore with explicit alias2025-05-06T07:07:54+00:00Jakob Unterwurzacher2025-05-06T07:07:54+00:00urn:sha1:e59f97806b12d593b972bbd17988f061fcc09043Report inode number for the root node2024-11-11T21:33:07+00:00Jakob Unterwurzacher2024-11-11T21:27:42+00:00urn:sha1:86891054ef2a5d1b0b59c7c140aae284e7c5bd87
Now that https://github.com/hanwen/go-fuse/issues/399 has
landed we can report an inode number for the root node.
Fixes https://github.com/rfjakob/gocryptfs/issues/580
reverse: fix import sorting in root_node.go2024-11-11T21:33:07+00:00Jakob Unterwurzacher2024-11-11T21:26:55+00:00urn:sha1:12c0f3a0bdd11444b8bf880af7c63ea7850391f2reverse: use unique generation number for all nodes2024-05-01T20:26:37+00:00Jakob Unterwurzacher2024-05-01T20:26:37+00:00urn:sha1:ed0a12b7337c2d88c027329f64e73070da17d5b3
We used to present gocryptfs.longname.*.name files for hardlinked
files as hardlinked to the kernel (same Node ID) which is wrong.
Fix this by using a unique generation number for all nodes, which
also fixes possible issues with inode reuse.
Basically what 1bc1db620b061aabf59469a5eb4fb60e3e1701a3 did
for forward mode with -sharedstorage.
Fixes https://github.com/rfjakob/gocryptfs/issues/802
make format2022-08-28T09:11:36+00:00Jakob Unterwurzacher2022-08-28T09:11:36+00:00urn:sha1:003a7fa2e53ac15d2c94a34102ae12b69b23c586Fix invalid -longnamemax for reverse mode2022-08-28T09:09:01+00:00NekoGirlSAIKOU2022-04-24T17:35:30+00:00urn:sha1:1bff80b46cf3cdd2d6934ebf905fca96dde7af97