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:

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

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.

  • What about echo -n "....". The echo will include an extra \n on you when you pipe that to base64.
    – slm
    Commented Jun 23, 2014 at 17:41
  • @slm s/echo/printf/ gives the exact same result, as far as I can tell. And the final newline shouldn't matter for base64 decoding. Still a good point; I'll update the question.
    – user
    Commented Jun 23, 2014 at 17:51

1 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

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

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


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


$ ./set-comment xyz 日本語
# file: xyz

$ 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.)


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:)

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

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

$ ./set-comment xyz 0x414243
# file: xyz


$ ./set-comment xyz 0s5pel5pys6Kqe
# file: xyz

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.

  • If anyone wants to edit this answer to just include the “answer” bit at the end, it’s OK by me. ... I had written the whole “forensics” bit before I got to the “read the man-page and find the answer” bit, so I didn’t just want to throw it away right away... It also shows some methods to how to find an answer when you have a “feeling” of what it should be, but it doesn’t match exactly...
    – Johan E
    Commented Jun 23, 2014 at 18:01
  • Perfect! And please do keep this the way it is. I can live with 0x and 0s being special cases; since they are printed right back at me, anything that ends up being interpreted in the "wrong" way will be caught quickly anyway.
    – user
    Commented Jun 23, 2014 at 18:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .