On Tue, 25 Mar 2025 at 14:26:42 +0100, László Böszörményi (GCS) wrote:

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.
[1] https://github.com/libfuse/libfuse/commit/3ae5ca7443348aabad9bc71b9d5b0999f8292379

I did a quick spot check on some of the flags and they seem to have the
same numeric values before and after 3ae5ca74 (including for example
(1<<2) being unused), so I don't think it's this.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 25 Mar 2025 at 13:47:33 +0000, Simon McVittie wrote:

I also wonder whether it would be better for fuse_set_feature_flag()
and fuse_unset_feature_flag() to set/unset the relevant flag in
conn->want *and* conn->want_ext, if it happens to be below the 32-bit >boundary. That way, "fuse_lower_32_bits(conn->want_ext) != conn->want"
would usually be false and we would not have any inconsistency.

Unfortunately fuse_set_feature_flag() and fuse_unset_feature_flag() are
inlined (somewhat defeating the purpose of encapsulating access to struct members...) so if this turns out to be part of a solution, then gvfs and
all other callers will need binNMUs to pick up that change.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)