NFSv4.1 OPENATTR support

[cedricblancher]

We need NFSv4.1 OPENATTR support. Could this be implemented for nfs4j, please?

[lionelconswork]

We need OPENATTR/O_XATTR-style alternate data streams too.

[lionelconswork]

Implementation for filesystems without ADS (Alternate Data Stream support) could be implemented with subdirs, e.g. a file "abc" would get a "abc@@nfsattrs" directory with sticky bit set. If "abc" gets deleted then the "abc@@nfsattrs" dir would be removed too.

[lionelconswork]

Testing:
pynfs has OPENATTR tests: https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=blob;f=nfs4.1/server41tests/st_xattr.py

[kofemann]

pynfs tests extended attribute (supported by nfs4j).
OPENATTR is something completely different and there are not plans to work on it ATM.

[lionelconswork]

On Wed, 26 Mar 2025 at 11:19, Tiramisu Mokka ***@***.***> wrote: pynfs tests extended attribute (supported by nfs4j). OPENATTR is something completely different and there are not plans to work on it ATM. — Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7RUL7NUEEPNSOJDBJS3HL2WJWJVAVCNFSM6AAAAABVA32LW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTHA4TGMRUGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: kofemann]*kofemann* left a comment (dCache/nfs4j#143) <#143 (comment)> pynfs tests extended attribute (supported by nfs4j). OPENATTR is something completely different and there are not plans to work on it ATM. — Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7RUL7NUEEPNSOJDBJS3HL2WJWJVAVCNFSM6AAAAABVA32LW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTHA4TGMRUGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Would you accept patches for OPENATTR support? Lionel

[kofemann]

Sure, if they don't break existing functionality :).
Please take a look at https://github.com/dCache/nfs4j?tab=readme-ov-file#how-to-contribute

[lionelconswork]

How would the preferred API in the interface VirtualFileSystem look like for you? Just openAttr(FileName f) to get the inode to the virtual attr dir?

[kofemann]

Yes, I have no idea yet what problem that will solve. For example, we are working currently on something that is called 'virtual directories'.

https://indico.cern.ch/event/1477299/contributions/6407503/attachments/3041040/5376579/dCache_hepix_2025.pdf

Is it in the same directon?

[lionelconswork]

Yes, I have no idea yet what problem that will solve. For example, we are working currently on something that is called 'virtual directories'.

https://indico.cern.ch/event/1477299/contributions/6407503/attachments/3041040/5376579/dCache_hepix_2025.pdf

Is it in the same directon?

No, what we are primarily looking for is multiple data streams per file, for multiple different usage scenarios, including:

• cache streams, e.g. keep a compressed version of the data stream, similar how Windows implements per-file compression, or multiple scaled bitmap versions of a SVG file etc)
• attribute storage in XML (without size limit)
• MacOS data+resource fork implementation for the upcoming OS X NFSv4.2 driver

[kofemann]

Got it. So, yeah, looks like openAttr(String name, boolean create) matches the nfs spec.

[cedricblancher]

FYI the Windows ms-nfs41-client project now (https://sourceforge.net/p/ms-nfs41-client/mailman/message/59282285/) has Win32 named stream support via NFS named attributes, so this RFE becomes a higher priority.