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

[Lionel Cons]

On 9 September 2014 23:29, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> Simon Toedt wrote:
>> On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem <rmacklem at uoguelph.ca>
>> wrote:
>> > Jordan Hubbard wrote:
>> >> Yep.  I was just describing the experience that OS X went through
>> >> in
>> >> implementing extattrs / legacy resource fork support.  To recap it
>> >> very briefly:  Having NFSv4 support extattrs (or even named
>> >> streams,
>> >> if you want to go that far) is the comparatively easy part.  It’s
>> >> backing them up / copying them around that gets more involved, and
>> >> if you can’t back up certain attributes then you’re not likely to
>> >> get anyone to want to use them, at which point the whole “sharing”
>> >> aspect kind of takes a back seat.
>> >>
>> > Yep. I strongly suspect you are correct.
>> >
>> > The question then becomes:
>> > - Do we wait and see if someone chooses to get around to doing all
>> >   the hard userland work.
>>
>> Solaris tools already have support for this. Also AT&T AST from David
>> Korn have support for O_XATTR, too.
>>
> Hopefully others will correct me if I have this incorrect, but I thought
> CDDL code could only be used for optional components of FreeBSD?
> I suspect tar and friends are considered core components and that code
> for this would have to be written by someone (ie. couldn't use CDDL code?).
> (I'm assuming that these tools are in OpenSolaris.)

I don't think you FreeBSD should *copy* the code. But it can be used
for reference how the extended tar headers for filesystem forks should
look like. That's all.

>
> Be aware that most of FreeBSD's development is done by volunteers in their
> spare time, so I have no idea if someone is interested in doing this.

If anyone can get the kernel parts I think we can sponsor someone to
do the userland work.

Lionel