sahib
Is the \0 stored in the xattrs for a checksum deliberate?
I was doing some programming that involved storing md5 checksums in a file's xattr, and I noticed that rmlint's storage of a checksum includes a 0 byte, which causes the listing (by xattr -lz and other commands) to be displayed in hex. I presume this happens because rmlint issues a setxattr call from C to save user.rmlint.md5.cksum in an xattr, and passes a length that includes the null byte of the string, whereas when I set user.checksum.md5 from the command line, the setfattr command-line command does not include the NUL byte?
user.rmlint.md5.cksum: 0000 30 39 65 33 30 61 31 35 65 35 61 37 34 64 65 61 09e30a15e5a74dea 0010 62 64 33 34 66 30 34 66 35 64 30 37 33 38 37 36 bd34f04f5d073876 0020 00 .
user.checksum.md5: 09e30a15e5a74deabd34f04f5d073876
I'm just wondering if this was a deliberate choice in the rmlint code and if so, why? If it was unintentional, would removing the terminating NUL byte in an updated release break backwards compatibility? It would certainly make the xattrs more readable and more easily used in other scripts.
thanks,
Graham
That's weird because strlen is used, so \0 should not be included. result = rm_sys_setxattr(path, key, cksum, strlen(cksum), 0, follow_symlinks);
That is indeed strange. Have you checked your own files to see if that 0x00 is there for you too? I can't imagine how but maybe it's just on my system? (Which would in itself be a fact worth knowing). Wait... I just had a look through the sources and maybe this is the culprit: rm_xattr_set(file, cksum_key, cksum_hex_str, sizeof(cksum_hex_str), follow)
sizeof() will include the NUL termination.
Hi @gtoal, as this issue has not, yet, been resolved in this repo, I have reopened it. In case the associated PR, from @speed47, is accepted and merged this issue will close automatically.
At this moment, unfortunately, I can't promise a new release of rmlint any time soon.
