> Out of the box, script will pass bs= option to dd for it to be aware of how much to skip from the beginning of input data (and on later while loop iterations). This seem to have handled by dd either improperly or at least in a different way than it was in the past (with GNU core utils). However, once bs= is replaced with ibs=, all seems to go back to normal.

The bs/ibs/obs options don't "skip" anything, but determine how much data to buffer in memory at a time while transferring. Regardless, it's hard to fathom how something this simple got messed up, especially considering that the suite supposedly has good test coverage and has been getting close to a full green bar.

▲ hulitu 17 hours ago | parent [-]

> However, once bs= is replaced with ibs=, all seems to go back to normal.

so it is a bug. bs is one thing, ibs is another.

▲ zahlman 17 hours ago | parent [-]

> bs is one thing, ibs is another.

  bs=BYTES
         read and write up to BYTES bytes at a time (default: 512); over‐
         rides ibs and obs

As described, the script should have worked as is, and the problem is in the handling of the dd options. (But I didn't verify the accuracy of the description.)

▲

lesuorac 16 hours ago | parent [-]

Wonder if `\00` is handled different between them. Not sure how to run the rust version but my md5sum seems to care how many null bytes there are.

echo -e "\00" | md5sum 8f7cbbbe0e8f898a6fa93056b3de9c9c -

echo -e "\00\00" | md5sum a4dd23550d4586aee3b15d27b5cec433 -

	▲	hiccuphippo 14 hours ago \| parent \| next [-]
		Kind of off-topic, but those commands also add a newline character to the md5sums, giving unexpected results. I was trying it in a php interpreter and getting different values. Add -n to echo to avoid the new line.
	▲	zahlman 15 hours ago \| parent \| prev [-]
		> Wonder if `\00` is handled different between them. `dd` is for copying all the bytes of a source (unless you explicitly set a limit with the `count` option), regardless of whether they're zero. It's fundamentally not for null-terminated strings but arbitrary binary I/O. In fact, "copying from" /dev/zero is a common use case. It seems frankly implausible that the `dd` implementation is just stopping at a null byte; that would break a lot of tests and demonstrate a complete, fundamental misunderstanding of what's supposed to be implemented. > Not sure how to run the rust version but my md5sum seems to care how many null bytes there are. Yes, the md5 algorithm also fundamentally operates on and produces binary data; `md5sum` just converts the bytes to a hex dump at the end. The result you get is expected (edit: modulo hiccuphippo's correct observation), because the correct md5 sum changes with every byte of input, even if that byte has a zero value.