Tool to access ZFS/NFSv4 alternate data streams on FreeBSD?

[John Baldwin]

On Friday, September 05, 2014 06:13:10 PM Rick Macklem wrote:
> Lionel Cons wrote:
> > On 5 September 2014 19:26, Richard Yao <ryao at gentoo.org> wrote:
> > > On 09/05/2014 11:35 AM, Jan Bramkamp wrote:
> > >> On 05.09.2014 16:25, Lionel Cons wrote:> Is there any tool which
> > >> can be
> > >> used to access ZFS and NFSv4 alternate
> > >> 
> > >>> data streams on FreeBSD?
> > >> 
> > >> Are you looking for lsextattr(8) and getextattr(8)?
> > >> _______________________________________________
> > >> freebsd-hackers at freebsd.org mailing list
> > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > >> To unsubscribe, send any mail to
> > >> "freebsd-hackers-unsubscribe at freebsd.org"
> > > 
> > > Do you mean Solaris extended attributes? Those tend to be called
> > > resource forks on other platforms. Unifying extended attributes and
> > > resource forks was clever.
> > 
> > Yes, they are also called resource forks, or alternate data streams.
> > The attribute files which can be accessed via O_XATTR or cd -@
> > file/dir on newer ksh/ksh93/bash revisions.
> 
> For FreeBSD's NFSv4 the answer is definitely no. Because the Linux/FreeBSD
> style setextattr() assumes an atomic replacement of the extended attribute,
> it is not semantically compatible (ie. cannot be accurately emulated) by
> resource forks.
> 
> I do not know of any work for ZFS on FreeBSD w.r.t. this, but I'm not a
> ZFS guy.

Does the NFSv4 protocol support resource forks as a separate entity from EAs 
though?  Presumably O_XATTR would turn into a new VOP (VOP_OPENFORK() or some 
such), it wouldn't be shoehorned into the EA APIs.

-- 
John Baldwin