Jhoward/macos xattr get all chars

[jrobhoward]

On macOS:

• XAttrUtil.setXAttr() was including a bonus \0 char to the end of all xattrs it created.
• XAttrUtil.getXAttr() was compensating/removing the bonus \0 char. This means all unit tests pass, but macOS JNA is unable to consume xattrs created via the command line. Any xattrs created via the command line will have their final char truncated.

Here is an example file with two xattrs. Each xattr is supposed to have a value of "1". The first was created using JNA, and the second was created using xattr -w user.samplecli 1 /tmp/jrh.jrh

JRHMBP:jna jhoward$ xattr -l /tmp/jrh.jrh
user.samplejna:
00000000  31 00                                            |1.|
00000002
user.samplecli: 1

The change associated with this PR is pretty straightforward. Let me know if you have any questions.

[matthiasblaesing]

Both codes look dangerous and strange. I'm primary a java developer, but from my experience with C, the normal convention is, that in C strings (aka char arrays) are terminated by a NULL character.

Given, that xattrs are basically mappings from strings to arbitrary byte strings (not limited to strings), I can see people storing both variants, but the man page has to say for the names: "An extended attribute's name is a simple NUL-terminated UTF-8 string." (see: http://www.polarhome.com/service/man/?qf=setxattr&af=0&tf=2&of=Darwin). So I would assume "normal" strings to be UTF-8 encoded and terminated by a NUL character.

The man page seems to be contradictory (https://ss64.com/osx/xattr.html):

[...]The metadata is often a null-terminated UTF-8 string, but can also be arbitrary binary data.[...]
[...]Attribute values are usually displayed as strings. However, if nils are detected in the data, the value is displayed in a hexadecimal representation.[...]

encodeString looks ok (it enforces the trailing \0 character), but getXAttr is broken. From my understanding decodeString should be implemented as Native.toString(xattrBuffer, StandardCharsets.UTF_8). Than you also don't need a ByteBuffer and can use a plain byte[]. decodeStringSequence can work on a byte[] and use the String(byte[], int offset, int length, Charset) constructor.

I hope this makes sense to you.

[matthiasblaesing]

@jrobhoward could you please have a look at #1100? That would be my implementation. With that implementation the behavior of XAttrUtil should match the CLI.

[matthiasblaesing]

Fixed via #1095