Control: clone -1 -2
Control: reassign -2 libfuse3-4
Control: retitle -2 libfuse3-4: regression in filesystems that use fuse_conn_info.want
Control: severity -2 important
Control: forwarded -2
https://github.com/libfuse/libfuse/issues/1171
On Sat, 22 Mar 2025 at 13:34:36 +0100, László Böszörményi (GCS) wrote:
On Sat, Mar 22, 2025 at 1:06 PM Jeremy Bícha <jeremy.bicha@canonical.com> wrote:
On Sat, Mar 22, 2025 at 7:51 AM Jens Yllman <jens@yllman.se> wrote:
So, the question is fuse doing this wrong or is gvfs-fuse doing it wrong? >>
I don't know. Someone should report the issue to the gvfs maintainers also.
Quick check done. It seems in the past FUSE capabilities were a 32
bit bitfield. It was moved to a 64 bit struct, causing an ABI break.
It was handled by the SONAME bump and more importantly the FUSE helper >functions started to use the new bitfield. See the mentioned bitfield >comments [1][2] in the FUSE header. Both say use the FUSE helper
functions fuse_set_feature_flag() and fuse_unset_feature_flag()
instead of accessing internal parts directly.
But then gvfs (even the one in Trixie / Sid) manipulates the old 32
bit bitfield directly [3] (and at other places). Meaning it is a gvfs
bug, a proposed fix is already provided [4].
In very short, gvfs needs to be fixed. I can't do anything on the FUSE side.
I'm actually not so sure that this is entirely gvfs' fault. From
discussion on the upstream (gvfs and FUSE) bug reports, it looks like
FUSE is meant to have backwards-compatibility for the deprecated 32-bit bitfield, so that packages like gvfs that still use it will still work;
but the backwards-compatibility doesn't work, hence the regression.
I've applied the proposed patch you referenced as [4] in gvfs, and I
think it would be a good thing for gvfs upstream to apply because it
moves them from a deprecated API to a non-deprecated one; but the same
issue could equally well affect other FUSE filesystems, so I think
ideally it would be good to get the backwards compatibility code path
working again in FUSE *as well* (following the principle that a bad
interaction between components is often most robustly fixed in both
components, not just one).
The FUSE issue is <
https://github.com/libfuse/libfuse/issues/1171> and a proposed fix is <
https://github.com/libfuse/libfuse/pull/1172>.
From
https://codesearch.debian.net/search?q=conn-%3Ewant&literal=1 it
looks like this could affect fuse-overlayfs, xdg-desktop-portal, ntfs-3g
for example (not verified).
An older gvfs taken from trixie or snapshot.debian.org is probably a
useful test-case for this.
Thanks,
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)