On Tue, Mar 25, 2025 at 1:39 PM Simon McVittie <s...@debian.org> wrote: > 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. [...] > 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. Yes, this is the recommended way to use the feature flag helper functions. I think the break might be caused by the FUSE_CAP_* enum -> defines conversion [1]. I need to check, but maybe the bits are changed? I mean with enum FUSE_CAP_ATOMIC_O_TRUNC might have a value of x and with defines now it might be value y. As gvfs was compiled with the former, might use different flags / values with FUSE v3.17.1 - need to check. But if this is the reason, gvfs will need a binNMU with the final FUSE v3.17.1 release.
Regards, Laszlo/GCS [1] https://github.com/libfuse/libfuse/commit/3ae5ca7443348aabad9bc71b9d5b0999f8292379
