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