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

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, May 06, 2026 at 12:04:41AM +0200, Theodore Tso wrote:
> On Tue, May 05, 2026 at 08:58:21AM -0700, Darrick J. Wong wrote:
> > Hrm.  A bisect would be the best (but least conference-friendly) option
> > to narrow things down.
> 
> Well, a bisect was a bit painful because I had to cherry-pick patches
> so I could get a successfull build.  But I did finally come up with
> the guilty commit, and it's.... surprising at least to me:
> 
> commit b0bd58062bbf645942ab4f0aced3bb229f462dde
> Author: Darrick J. Wong <djwong@kernel.org>
> Date:   Thu Aug 28 10:30:40 2025 -0700
> 
>     fuse2fs: cache symlink targets in the kernel
> 
>     Speed up symlinks by allowing the kernel to cache them.
> 
>     Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> 
> I don't know why it made a difference, but this attached patch appears
> fix the MacOS regression.  Could this be a bug in MacFuse[1]?  FWIW, I'm
> running MacFuse 5.2.0_1 from MacPorts.
> 
> [1] https://macfuse.github.io
> 
> I could condition the patch so that we only avoid setting
> FUSE_CAP_CACHE_SYMLINKS on MacOS?  WDYT?

I vomit a little in my mouth, because...

$ cd macfuse/Library-3
$ git grep FUSE_CAP_CACHE_SYMLINKS
<snip>
include/fuse_common.h:472:#define FUSE_CAP_CACHE_SYMLINKS (1UL << 23)

Ok, so fuse2fs passes want-flag 1<<23 into the kernel to turn on what it
*thinks* are cached symlinks.

[Editor's note: this email previously contained the following text]

    Unfortunately, we both now hit a brick wall, because the macfuse
    page says:

    "This repository contains the source code of libfuse.dylib and
    macFUSE.framework. The other components, e.g. the macFUSE kernel
    extension, are closed-source."

    Hence we have no way to find out what the kext thinks 1<<23 means.
    There's talk of some sort of "fskit" replacement for the signed
    kext, but I don't know where that is.

Actually, it's *MUCH* worse than that.  Look at what
Library-3/include/fuse_kernel.h contains:

#ifdef __APPLE__
/*
 * TODO(bf)
 *
 * Resolve conflict with vanilla API. As long as we don't support anything
 * beyond 7.19 on the kernel-side this should not be an issue. We need to clean
 * this up when moving to 7.20 or later.
 */
#define FUSE_DARWIN_ACCESS_EXT        (1 << 23)
#define FUSE_DARWIN_THREAD_SAFE        (1 << 24)
#define FUSE_DARWIN_RENAME_EXT        ((1 << 25) | (1 << 26))
#define FUSE_DARWIN_FALLOCATE        (1 << 27)
#define FUSE_DARWIN_CASE_INSENSITIVE    (1 << 29)
#define FUSE_DARWIN_SETVOLNAME        (1 << 30)
#endif

Then look up about 30 lines:

#define FUSE_CACHE_SYMLINKS	(1 << 23)
#define FUSE_NO_OPENDIR_SUPPORT (1 << 24)
#define FUSE_EXPLICIT_INVAL_DATA (1 << 25)
#define FUSE_MAP_ALIGNMENT	(1 << 26)
#define FUSE_SUBMOUNTS		(1 << 27)
#define FUSE_HANDLE_KILLPRIV_V2	(1 << 28)
#define FUSE_SETXATTR_EXT	(1 << 29)
#define FUSE_INIT_EXT		(1 << 30)

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.

$searchengine has zero hits for FUSE_DARWIN_ACCESS_EXT so who knows what
that actually does.  But this sure is a messed up situation.

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

--D

> 						- Ted

> From fb3d2fc975d17d97ed76b2ed76022462a3b329f1 Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Tue, 5 May 2026 23:34:53 +0200
> Subject: [PATCH] Revert "fuse2fs: cache symlink targets in the kernel"
> 
> This reverts commit b0bd58062bbf645942ab4f0aced3bb229f462dde.
> 
> This commit is apparently causing fuse2fs on MacOS to fail without "-o
> default_permissions".  It's not clear why, but it was determined using
> a git bisect, and reverting the commit addresses the regression.
> 
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
>  misc/fuse2fs.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
> index c46cfc23..0f9cefa6 100644
> --- a/misc/fuse2fs.c
> +++ b/misc/fuse2fs.c
> @@ -1593,9 +1593,6 @@ static void *op_init(struct fuse_conn_info *conn,
>  	if (ff->acl)
>  		fuse_set_feature_flag(conn, FUSE_CAP_POSIX_ACL);
>  #endif
> -#ifdef FUSE_CAP_CACHE_SYMLINKS
> -	fuse_set_feature_flag(conn, FUSE_CAP_CACHE_SYMLINKS);
> -#endif
>  #ifdef FUSE_CAP_NO_EXPORT_SUPPORT
>  	fuse_set_feature_flag(conn, FUSE_CAP_NO_EXPORT_SUPPORT);
>  #endif
> -- 
> 2.50.1 (Apple Git-155)
>