* Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork [not found] ` <20260506092858.GC49070@macsyma.local> @ 2026-05-06 14:34 ` Darrick J. Wong 2026-05-06 15:08 ` Theodore Tso 0 siblings, 1 reply; 3+ messages in thread From: Darrick J. Wong @ 2026-05-06 14:34 UTC (permalink / raw) To: Theodore Tso; +Cc: Ext4 Developers List, fuse-devel [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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork 2026-05-06 14:34 ` [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Darrick J. Wong @ 2026-05-06 15:08 ` Theodore Tso 2026-05-06 16:39 ` Darrick J. Wong 0 siblings, 1 reply; 3+ messages in thread From: Theodore Tso @ 2026-05-06 15:08 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Ext4 Developers List, fuse-devel On Wed, May 06, 2026 at 07:34:13AM -0700, Darrick J. Wong wrote: > [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. This is the patch for fuse2fs and fuse4fs in e2fsprogs which works around the problem (tested on MacOS using macfuse 5.2.0_1 from MacPorts). More details about why it was needed is in the commit description. - Ted From 67f1ec55a1309abead16cad883e38b798a567191 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o <tytso@mit.edu> Date: Wed, 6 May 2026 10:51:56 -0400 Subject: [PATCH] fuse2fs, fuse4fs: Fix MacFuse compatibility issue Unfortunately, MacFuse is overloading the top bits of the flags field in struct fuse_init_{out} for MacFuse-specific capability extensions. This results in an attempt to use FUSE_CAP_CACHE_SYMLINKS when linking with the libfuse in MacPorts will end up enabling FUSE_DARWIN_CAP_ACCESS_EXT with MacFuse. Hilarity then ensues with all non-privileged access failing with permission denied. The change which is needed in MacFuse is described in a TODO(bf) statement: https://github.com/macfuse/library/blob/ddb630db8327a50b6670ef5e4f5e6da82a549e99/lib/fuse_lowlevel.c#L3415 I plan to submit a bug report to MacFuse, but in the mean time, work around the problem by disabling the overloaded capability flags on MacOS. Link: https://lore.kernel.org/r/20260505225635.GT7765@frogsfrogsfrogs Link: https://lore.kernel.org/r/20260506092858.GC49070@macsyma.local Signed-off-by: Theodore Ts'o <tytso@mit.edu> --- fuse4fs/fuse4fs.c | 18 ++++++++++++++++++ misc/fuse2fs.c | 18 ++++++++++++++++++ 2 files changed, 36 insertions(+) diff --git a/fuse4fs/fuse4fs.c b/fuse4fs/fuse4fs.c index 92847326..2739da92 100644 --- a/fuse4fs/fuse4fs.c +++ b/fuse4fs/fuse4fs.c @@ -120,6 +120,24 @@ #endif #endif /* !defined(ENODATA) */ +#ifdef __APPLE__ +/* + * Sigh.... MacFuse is overloading the top bits of the flags field in + * struct fuse_init_{out} for MacFuse-specific capability extensions. + * Avoid using these fuse3 capability flags until this gets fixed in + * MacFUSE + */ +#undef FUSE_CAP_CACHE_SYMLINKS +#undef FUSE_CAP_NO_OPENDIR_SUPPORT +#undef FUSE_CAP_EXPLICIT_INVAL_DATA +#undef FUSE_CAP_EXPIRE_ONLY +#undef FUSE_CAP_SETXATTR_EXT +#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP +#undef FUSE_CAP_PASSTHROUGH +#undef FUSE_CAP_NO_EXPORT_SUPPORT +#undef FUSE_CAP_OVER_IO_URING +#endif + #define FUSE4FS_ATTR_TIMEOUT (0.0) static inline uint64_t round_up(uint64_t b, unsigned int align) diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c index c46cfc23..0f2a3c35 100644 --- a/misc/fuse2fs.c +++ b/misc/fuse2fs.c @@ -116,6 +116,24 @@ #endif #endif /* !defined(ENODATA) */ +#ifdef __APPLE__ +/* + * Sigh.... MacFuse is overloading the top bits of the flags field in + * struct fuse_init_{out} for MacFuse-specific capability extensions. + * Avoid using these fuse3 capability flags until this gets fixed in + * MacFUSE + */ +#undef FUSE_CAP_CACHE_SYMLINKS +#undef FUSE_CAP_NO_OPENDIR_SUPPORT +#undef FUSE_CAP_EXPLICIT_INVAL_DATA +#undef FUSE_CAP_EXPIRE_ONLY +#undef FUSE_CAP_SETXATTR_EXT +#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP +#undef FUSE_CAP_PASSTHROUGH +#undef FUSE_CAP_NO_EXPORT_SUPPORT +#undef FUSE_CAP_OVER_IO_URING +#endif + static inline uint64_t round_up(uint64_t b, unsigned int align) { unsigned int m; -- 2.50.1 (Apple Git-155) ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork 2026-05-06 15:08 ` Theodore Tso @ 2026-05-06 16:39 ` Darrick J. Wong 0 siblings, 0 replies; 3+ messages in thread From: Darrick J. Wong @ 2026-05-06 16:39 UTC (permalink / raw) To: Theodore Tso; +Cc: Ext4 Developers List, fuse-devel On Wed, May 06, 2026 at 05:08:33PM +0200, Theodore Tso wrote: > On Wed, May 06, 2026 at 07:34:13AM -0700, Darrick J. Wong wrote: > > [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. > > This is the patch for fuse2fs and fuse4fs in e2fsprogs which works > around the problem (tested on MacOS using macfuse 5.2.0_1 from > MacPorts). More details about why it was needed is in the commit > description. > > - Ted > > From 67f1ec55a1309abead16cad883e38b798a567191 Mon Sep 17 00:00:00 2001 > From: Theodore Ts'o <tytso@mit.edu> > Date: Wed, 6 May 2026 10:51:56 -0400 > Subject: [PATCH] fuse2fs, fuse4fs: Fix MacFuse compatibility issue > > Unfortunately, MacFuse is overloading the top bits of the flags field > in struct fuse_init_{out} for MacFuse-specific capability extensions. > This results in an attempt to use FUSE_CAP_CACHE_SYMLINKS when linking > with the libfuse in MacPorts will end up enabling > FUSE_DARWIN_CAP_ACCESS_EXT with MacFuse. Hilarity then ensues with > all non-privileged access failing with permission denied. > > The change which is needed in MacFuse is described in a TODO(bf) > statement: > > https://github.com/macfuse/library/blob/ddb630db8327a50b6670ef5e4f5e6da82a549e99/lib/fuse_lowlevel.c#L3415 > > I plan to submit a bug report to MacFuse, but in the mean time, work around > the problem by disabling the overloaded capability flags on MacOS. > > Link: https://lore.kernel.org/r/20260505225635.GT7765@frogsfrogsfrogs > Link: https://lore.kernel.org/r/20260506092858.GC49070@macsyma.local > Signed-off-by: Theodore Ts'o <tytso@mit.edu> Looks fine for now... Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> --D > --- > fuse4fs/fuse4fs.c | 18 ++++++++++++++++++ > misc/fuse2fs.c | 18 ++++++++++++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/fuse4fs/fuse4fs.c b/fuse4fs/fuse4fs.c > index 92847326..2739da92 100644 > --- a/fuse4fs/fuse4fs.c > +++ b/fuse4fs/fuse4fs.c > @@ -120,6 +120,24 @@ > #endif > #endif /* !defined(ENODATA) */ > > +#ifdef __APPLE__ > +/* > + * Sigh.... MacFuse is overloading the top bits of the flags field in > + * struct fuse_init_{out} for MacFuse-specific capability extensions. > + * Avoid using these fuse3 capability flags until this gets fixed in > + * MacFUSE > + */ > +#undef FUSE_CAP_CACHE_SYMLINKS > +#undef FUSE_CAP_NO_OPENDIR_SUPPORT > +#undef FUSE_CAP_EXPLICIT_INVAL_DATA > +#undef FUSE_CAP_EXPIRE_ONLY > +#undef FUSE_CAP_SETXATTR_EXT > +#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP > +#undef FUSE_CAP_PASSTHROUGH > +#undef FUSE_CAP_NO_EXPORT_SUPPORT > +#undef FUSE_CAP_OVER_IO_URING > +#endif > + > #define FUSE4FS_ATTR_TIMEOUT (0.0) > > static inline uint64_t round_up(uint64_t b, unsigned int align) > diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c > index c46cfc23..0f2a3c35 100644 > --- a/misc/fuse2fs.c > +++ b/misc/fuse2fs.c > @@ -116,6 +116,24 @@ > #endif > #endif /* !defined(ENODATA) */ > > +#ifdef __APPLE__ > +/* > + * Sigh.... MacFuse is overloading the top bits of the flags field in > + * struct fuse_init_{out} for MacFuse-specific capability extensions. > + * Avoid using these fuse3 capability flags until this gets fixed in > + * MacFUSE > + */ > +#undef FUSE_CAP_CACHE_SYMLINKS > +#undef FUSE_CAP_NO_OPENDIR_SUPPORT > +#undef FUSE_CAP_EXPLICIT_INVAL_DATA > +#undef FUSE_CAP_EXPIRE_ONLY > +#undef FUSE_CAP_SETXATTR_EXT > +#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP > +#undef FUSE_CAP_PASSTHROUGH > +#undef FUSE_CAP_NO_EXPORT_SUPPORT > +#undef FUSE_CAP_OVER_IO_URING > +#endif > + > static inline uint64_t round_up(uint64_t b, unsigned int align) > { > unsigned int m; > -- > 2.50.1 (Apple Git-155) > ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-06 16:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260504233301.2345652-1-tytso@mit.edu>
[not found] ` <20260505000831.GA1101423@frogsfrogsfrogs>
[not found] ` <20260505072144.GC16497@macsyma-wired.lan>
[not found] ` <20260505155821.GI1101423@frogsfrogsfrogs>
[not found] ` <20260505220441.GB49070@macsyma.local>
[not found] ` <20260505225635.GT7765@frogsfrogsfrogs>
[not found] ` <20260506092858.GC49070@macsyma.local>
2026-05-06 14:34 ` [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Darrick J. Wong
2026-05-06 15:08 ` Theodore Tso
2026-05-06 16:39 ` Darrick J. Wong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox