What is this seemingly base64 data set by setfattr?

Question

I have written a short shell script that simply wraps setfattr in a slightly more convenient form for setting the extended attribute that corresponds to a free-text comment:

#!/bin/sh
test "$2" && setfattr -n user.xdg.comment -v "$2" "$1"
getfattr -d -m '^user.xdg.comment$' "$1"

For storing US ASCII comments as xattrs, this works great. However, if I try to set a comment that contains non US ASCII characters, it gives me back what appears to be Base64 encoded data:

$ touch xyz
$ set-comment xyz åäöåä
# file: xyz
user.xdg.comment=0sw6XDpMO2w6XDpA==
$ 

But it isn't just Base64:

$ printf "0sw6XDpMO2w6XDpA==" | \base64 --decode
��:\:L;l:\:@base64: invalid input
$ 

Most of the time, I get just random-looking garbage back. Some times, like this, the Base64 decoder throws "invalid input" back at me.

What is this string? What is its relationship to the original input value? How do I go from what getfattr gives me back to the original input value (such as åäöåä in this case)?

setfattr --version on my system responds with setfattr 2.4.46. I'm running the version packaged by Debian Wheezy. In the unlikely event that it matters, I'm running ZFS On Linux 0.6.3 (saw the same behavior with 0.6.2 as well) on the stock Wheezy kernel.

Answer 1

I got a bit curious reading this questoion, so let’s do some “forensics”:

First trying the opposite:

How is åäöåä encoded in Base64?

$ echo åäöåä | base64
w6XDpMO2w6XDpAo=

This clearly looks a lot like the 0sw6XDpMO2w6XDpA== that you’ve got. There’s an extra 0s at the beginning, and the end doesn’t exactly match. Suppressing the newline at the end of åäöåä (automatically inserted by echo), we get:

$ echo -n åäöåä | base64
w6XDpMO2w6XDpA==

This is exactly the user.xdg.comment-value except the 0s at the start.

Conclusion

The comment is Base64 encoded and prefixed with 0s, and testing a few other strings confirms this.

Example:

$ ./set-comment xyz 日本語
# file: xyz
user.xdg.comment=0s5pel5pys6Kqe

$ base64 -d <<<'5pel5pys6Kqe' ; echo
日本語

(where the ; echo is to not mess up the next prompt since the output of base64 does not end in a new-line.)

However...

This just shows that in these cases (where the comment is non-ASCII), it gets encoded in Base64 and prefixed with 0s.

The “real” answer

After doing this I got the splendid idea of checking the man-page for getfattr and it mentions, among other things:

Regarding th option -e en, --encoding=en

Encode values after retrieving them. Valid values of en are "text", "hex", and "base64". Values encoded as text strings are enclosed in double quotes ("), while strings encoded as hexidecimal and base64 are prefixed with 0x and 0s, respectively.

So, changing your script to:

(File set-comment:)

#!/bin/sh
test "$2" && setfattr -n user.xdg.comment -v "$2" "$1"
getfattr -e text -d -m '^user.xdg.comment$' "$1"

will always print the attribute as text, giving, for example:

$ ./set-comment xyz åäöåä   # with fixed script
# file: xyz
user.xdg.comment="åäöåä"

However, there is still some caveats left... like:

$ ./set-comment xyz 0x414243
# file: xyz
user.xdg.comment="ABC"

and

$ ./set-comment xyz 0s5pel5pys6Kqe
# file: xyz
user.xdg.comment="日本語"

where the output doesn’t match the input.

These can be fixed by “massaging” the argument into a form that setfattr likes. See man setfattr.