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 <[email protected]> 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 <[email protected]> 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 > [email protected] > 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)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
