No that doesn't make sense, this can't be intended behaviour, even if
you escape the backslash there should be no backslash in the beginning
of the checksum!
On 13.10.23 16:21, Pádraig Brady wrote:
tag 66519 notabug
close 66519
stop
On 13/10/2023 13:31, Simon Richter M. Sc. wrote:
I noticed some broken checksums with leading backslash and wrong
filenames in my checksum files because the original filenames contained
a backslash.
Way to reproduce:
% touch test\\test.file
% b2sum test\\test.file
expected output:
786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce
test\test.file
real broken output:
\786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce
test\\test.file
This is expected.
File names with problematic characters like \n are escaped as above.
Note we escape '\' itself to provide some forward compatibility
to introduce escaping of other characters.
Tested with coreutils 9.3 and coreutils 9.4 and LC_ALL=C
Btw any chance we get b3sum included in coreutils?
Yes we'll look at this,
but it will only be provided through the `cksum -a blake3` interface.
cheers,
Pádraig
