Oh well... In my case, its the CLI that would get used the most, anyway. This is because of the semi-automated paperless workflow I had mentioned earlier. But I would be quite reluctant at this time to go with the workround you mention (read & wrirte with FileBot) and ending up with \0 terminated ...

This is great news! Not enabling the fix by default is quite understadable at least at this stage. But it will be possible to enable it via some option/switch, right? (BTW, was the culprit indeed within the JNA code?) ---- With regards to your comments about the HEX ouput coming out of xattr -p ...

I have done a bit more digging on this topic, including skimming through some of the FileBot source code kindly made available on github. Sure enough, filebot simply calls a platform specific JNA ( com.sun.jna.platform.mac.XAttrUtil ) for accessing xattrs without doing anything funky on its own ...

Thanks a lot for this detailed response, rednoah. I guess I will have to see what convention is actually going to be expected by other software that will make up my toolchain. If null-terminated strings do not cause trouble in those tools, then we now have two alternate methods for setting them (via ...

Hi, There appears to be a small but very crippling bug relating to this "xattr" feature... The last character of an extended attribute's value is simply absent (truncated), when used in any format . Here are $ touch sample.txt $ xattr -w net.filebot.ut.greeting "Hello" sample.txt $ xattr -p net ...