Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork

Darrick J. Wong
2026-05-06T14:34:14Z

[cc fuse-devel]

TLDR for the fuse developers: Ted and I discovered a collision between
the upstream libfuse feature bits and the MacFUSE feature bits, which
causes macfuse to do the wrong thing if you try to enable symlink
pagecache.

https://lore.kernel.org/linux-ext4/20260505225635.GT7765@frogsfrogsfrogs/

On Wed, May 06, 2026 at 11:28:58AM +0200, Theodore Tso wrote:
> On Tue, May 05, 2026 at 03:56:35PM -0700, Darrick J. Wong wrote:
> > FUSE kABI 7.20 added FUSE_AUTO_INVAL_DATA, which is bit 12. It looks to
> > me as though they decided to add their own MacOS-specific feature flags
> > at the end of the u32 want field. Then Linux FUSE added 11 more feature
> > flags, at which point they unthinkingly ported over FUSE_CACHE_SYMLINKS,
> > which collides with FUSE_DARWIN_ACCESS_EXT. Apparently nobody on the
> > macfuse end noticed, so on your machine you're getting whatever
> > "ACCESS_EXT" does.
>
> Yeah....
>
> What MacFuse needs to do is to steal some extra fields from struct
> fuse_init_in and fuse_init_out for the darwin-specific capabilities.
> It turns out it already has conn->{want,capable}_darwin, but there's
> no way to pass it in and out of op_init....
>
> #ifdef __APPLE__
> /*
> * TODO(bf)
> *
> * Resolve conflict with vanilla API. We need a separate field flags for
> * Darwin-only flags. As long as we don't support anything beyond ABI
> * version 7.19 on the kernel-side this should not be an issue, though.
> * We need to clean this up when moving to 7.20 or later.
> */
> if (se->conn.want_darwin & FUSE_DARWIN_CAP_ACCESS_EXT)
> outargflags |= FUSE_DARWIN_ACCESS_EXT;
>
> So I *guess* what MacFuse needs to do is to do something like:
>
> struct fuse_init_in {
> uint32_t major;
> uint32_t minor;
> uint32_t max_readahead;
> uint32_t flags;
> uint32_t flags2;
> uint32_t unused[9];
> uint32_t darwin_flags;
> uint32_t darwin_flags2;
> };
>
> am I right in understanding that fuse_*_{in,out} is private between
> the OS's libfuse and OS's fuse driver or kernel extension, so
> it's not disastrous for fuse_kernel.h for Mac and Linux to drift?

Yeah, the easiest method would be to carve out the darwin_flags field.

If they still want to use flags/flags2, then they could probably still
fix it by redefining whichever feature was added later (probably
FUSE_CACHE_SYMLINKS) because right now they're broken, so it's not an
ABI break to redefine the symbol.

Either way someone will have to talk to the MacFUSE people about this.

> > Does this work?
> >
> > /* MacFUSE overlays feature bits with LinuxFUSE, this is fcked up */
> > #if defined(FUSE_CAP_CACHE_SYMLINKS) && !defined(FUSE_CACHE_SYMLINKS)
> > fuse_set_feature_flag(conn, FUSE_CAP_CACHE_SYMLINKS);
> > #endif
>
> What I'm thinking about doing is adding at the beginning of
> fuse[24]fs.c:
>
> #ifdef __APPLE__
> /*
> * Sigh.... MacFuse is overloading the top bits of the flags field of
> * struct fuse_init_{out} so we have to avoid using these capability
> * flags until this gets fixed in MacFUSE
> */
> #undef FUSE_CACHE_SYMLINKS
> #undef FUSE_NO_OPENDIR_SUPPORT
> #undef FUSE_EXPLICIT_INVAL_DATA
> #undef FUSE_MAP_ALIGNMENT
> #undef FUSE_SUBMOUNTS
> #undef FUSE_HANDLE_KILLPRIV_V2
> #undef FUSE_SETXATTR_EXT
> #undef FUSE_INIT_EXT
> #endif

That works for now. If macfuse fixes themselves, then I guess we could
turn that into a configure check.

--D

>
> - Ted