Ben:

You are correct.  I think we have put some sort of conversion in the
getattr call.  Regardless, we can fix this.  I am also going to let another
developer, who is more familiar with the pvfs_getxattr call respond.  I am
recalling things from memory (not always a good thing :-).

Becky

On Fri, May 8, 2015 at 10:46 AM, Ben Collins <be...@servergy.com> wrote:

> Thanks Becky,
>
> Just to point out the documentation:
>
> “The value of an extended attribute is a chunk of arbitrary textual or
> binary data of specified length.”
>
> So there should be no assumption of the value being a string of any kind.
> The [gs]etxattr() functions have the value typed to void* as well.
>
> I think it’s best to let the caller of either function assume
> responsibility for the null termination of their own value (if needed), and
> none should be added or accounted for.
>
> Also, I tried getfattr and it returned a base64 encoding of the binary
> value, which decoded to 6 bytes of data, as expected.
>
> > On May 8, 2015, at 10:33 AM, Becky Ligon <li...@clemson.edu> wrote:
> >
> > Ben:
> >
> > I think those values are stored as a character string in both cases, the
> kernel version and our version; however, pvfs is not reporting the correct
> length, from a posix point of view.   We will put that on our "todo" list.
> Thanks for bringing that to our attention, although, be aware that pvfs is
> not totally posix compliant and you may find other issues like this.
> >
> > Becky
> >
> > On Fri, May 8, 2015 at 9:45 AM, Ben Collins <be...@servergy.com> wrote:
> > I’m trying to switch from using sycall/kernel-driver to direct pvfs_*()
> functions. A major issue is that pvfs_getxattr() returns a length 1 byte
> longer than syscalls, as shown:
> >
> >
> > svy@papp1:~$ sudo attr -l /srv/data/cyphre-v2/user0
> > Attribute "cyphre.owner" has a 6 byte value for /srv/data/cyphre-v2/user0
> >
> > svy@papp1:~$ sudo ./attr-test /srv/data/cyphre-v2/user0
> > user.cyphre.owner is 7 bytes
> >
> > Note that 6 is the correct answer. It’s the length I set with setxattr().
> >
> > The second program was a quick one I write using pvfs_getxattr() where
> as the first one is using the attr program, so it uses getxattr() syscall
> directly, and goes through the kernel driver.
> >
> > If I do something like:
> >
> >         len = pvfs_getxattr(path, key, NULL, 0);
> >         len—; // True length
> >         buf = malloc(len);
> >         len = pvfs_getxattr(path, key, buf, len);
> >
> > I get data that is, technically, the right length, but truncated by one
> byte (last byte is ‘\0’). My assumption (without digging too deep) is that
> the pvfs function adds an extra byte to null terminate the buffer, but it
> definitely shouldn’t do this (keys, sure, but not values).
> >
> > Either way, this makes the pvfs wrapper incompatible with the posix
> functions.
> >
> > ——
> > Ben Collins
> > Cyphre Champion
> > ——————————————
> > VP of Engineering
> > Servergy, Inc.
> >
> > _______________________________________________
> > Pvfs2-developers mailing list
> > Pvfs2-developers@beowulf-underground.org
> > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
> >
> >
> >
> >
> > --
> > Becky Ligon
> > Research Associate
> > Clemson University
> > Clemson, SC
>
> ——
> Ben Collins
> Cyphre Champion
> ——————————————
> VP of Engineering
> Servergy, Inc.
> 469-919-5634 (O)
> 757-243-7557 (M)
>
>


-- 
Becky Ligon
Research Associate
Clemson University
Clemson, SC
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to