Package: libfuse3-4
Version: 3.17.1-1
Severity: serious
Justification: regression in code that is (AFAICS) following upstream
recommendations
X-Debbugs-Cc: Michael Anderson <[email protected]>, Vladimir K
<[email protected]>
Control: affects -1 + src:gvfs gvfs-fuse
On Tue, 25 Mar 2025 at 09:34:40 +0000, Michael Anderson wrote:
>Thanks for the previous fix which did work.
>
>However it has broken again with libfuse3-4 updating from 3.17.1~rc1-3
>to 3.17.1-1.
On Tue, 25 Mar 2025 at 14:17:32 +0300, Vladimir K wrote:
>It worked, but broke again.
>
> $ eng apt list --installed fuse3 gvfs-fuse libfuse*
> fuse3/unstable,now 3.17.1-1 amd64 [installed,automatic]
> gvfs-fuse/unstable,now 1.57.2-2 amd64 [installed]
> libfuse2t64/unstable,now 2.9.9-9 amd64 [installed,automatic]
> libfuse3-4/unstable,now 3.17.1-1 amd64 [installed,automatic]
>
> $ /usr/libexec/gvfsd-fuse -f /run/user/1000/gvfs
> fuse: both 'want' and 'want_ext' are set
Laszlo, I assume this is not the result you expected after updating
fuse3? In gvfs-fuse_1.57.2-2, the only references to FUSE_CAP are:
client/gvfsfusedaemon.c: fuse_set_feature_flag(conn, FUSE_CAP_ATOMIC_O_TRUNC);
client/gvfsfusedaemon.c: fuse_unset_feature_flag(conn, FUSE_CAP_ASYNC_READ);
which if I understand correctly is the style that is recommended by the
upstream developers of FUSE. I verified that this worked as intended with
libfuse3-4_3.17.1~rc1-3, but I can confirm the regression with 3.17.1-1.
If necessary we can revert to the old code in gvfs as a workaround:
conn->want |= FUSE_CAP_ATOMIC_O_TRUNC;
conn->want &= ~FUSE_CAP_ASYNC_READ;
but I'm aware that that's unlikely to be very future-proof, and I'd like
to avoid getting into a cycle of fuse3 and gvfs working around each
other!
Thanks,
smcv
