On Tuesday 25 February 2025 16:41:37 Dave Chinner wrote: > Your call - windows attribute support via a small amount of work for > an existing API addition, or a huge amount of work across the entire > filesystem ecosystem for a whole new API. The end functionality will > be identical, but one path is a whole lot less work for everyone > than the other.... > > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx So, would you rather see a change which defines all windows attributes in fsx_xflags field, without any mask fields, and if there is no space in fsx_xflags field anymore, define new fsx_xflags2 field? I can prepare new RFC with this approach, and we can compare and discuss what is better. Just to note, that NFS4 protocol for supported subset of windows attribute has for each attribute 3 state value: unsupported, unset, set. So for knfsd it would be beneficial from filesystem driver to provide information if particular attribute is supported or not (and not only if attribute is set or unset). It does not have to be via this interface. But my approach with mask field can easily provide this information.
