Summary:
sha256sum (and possibly the other *sum tools) correctly calculates
and records checksums for files whose names contain a carriage return,
escaping the carriage return as \r, but then refuses to check those
files when invoked with --check (-c). The exit code for the process
checking the files reflects success, even though not all of the files
were checked.
Version and platform:
sha256sum (uutils coreutils) 0.10.0
Linux 7.0.0-38-generic x86_64
Ubuntu 26.04.1 LTS
Filesystem ext4
Steps to reproduce:
$ pushd $(mktemp -d)
$ pwd
$ echo a > $'Icon\r'
$ echo b > foo
$ echo c > bar
$ find . -type f -exec sha256sum {} + > /tmp/sums.sha256
$ mv /tmp/sums.sha256 .
$ cat -e sums.sha256
$ sha256sum -c --quiet sums.sha256 && echo SUCCESS || echo FAILURE
$ popd
Expected result:
All files are checked and the exit code reflects success only if all
files pass.
Actual result:
Files with carriage returns in the filenames are skipped by the
check run, but the exit code still reports success.
Notes:
This problem surfaces when files from macOS computers are backed up
to a Linux machine running the GNU coreutils implementation of
sha256sum. The OS for the machine being backed up is known to generate
filenames containing a carriage return ("Icon\r") for some reason. The
version of sha256sum running on BSD servers behaves correctly for this
case, checking all the files.
There's no real barrier preventing the tool from checking all the
files, as demonstrated by the fact that it was able to generate the
checksums correctly when run without the -c option. I was able to work
around the problem by writing my own Python script to check the files,
unescaping the filenames where necessary in order to open the files
for reading.
Thanks,
Bob Kline
