check failed when filename ends with space

[JensKuehnel]

tested with rhash 1.4.2 commit 9903be0cb94b84188f9b3a42d6b6b8ca5073372e on Fedora35 / Debian11

$ mkdir a
$ echo "hello world" > "a/b "
$ rhash --crc32c -r a > result
$ rhash -c result
--( Verifying result )----------------------------------------------------------
a/b                                                 No such file or directory
--------------------------------------------------------------------------------
Errors Occurred: Errors:0   Miss:1   Success:0   Total:1  

output of make print-info:

cd librhash && make print-info
make[1]: Entering directory '/home/user/git/RHash/librhash'
cc -c -DOPENSSL_RUNTIME -O2 -DNDEBUG -pipe -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -W -Wstrict-prototypes -Wnested-externs -Winline -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement  test_hashes.c -o test_hashes.o
cc -DOPENSSL_RUNTIME -O2 -DNDEBUG -pipe -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -W -Wstrict-prototypes -Wnested-externs -Winline -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement  test_hashes.o librhash.so.0   -o test_shared
LD_LIBRARY_PATH=.: DYLD_LIBRARY_PATH=.: ./test_shared --info
Compile-time flags: __k8__ __amd64 __amd64__ __x86_64 __x86_64__ _LP64 __LP64__ __VERSION__=11.2.1 20211203 (Red Hat 11.2.1-7) (__GNUC__=11,__GNUC_MINOR__=2) __STDC_VERSION__=201710L _POSIX_VERSION=200809L _POSIX_C_SOURCE=200809L __linux __GLIBC__ OPENSSL_RUNTIME HAS_STDC_ALIGNED_ALLOC CPU_X64 IS_LITTLE_ENDIAN (__BYTE_ORDER==__LITTLE_ENDIAN)
OpenSSL supported, loaded: MD4 MD5 SHA1 WHIRLPOOL RIPEMD-160 SHA-224 SHA-256 SHA-384 SHA-512
make[1]: Leaving directory '/home/user/git/RHash/librhash'

[rhash]

RHash works as designed, all paths parsed from a hash file are trimmed (i.e. trailing and starting spaces are removed).

This is done to simplify parsing of hash files. Hash files are stored in text format where a space is considered a separator. In the "simple" hash file format a space (or a group of spaces) is located before a file path, while in SFV format it is located after the file path:

$ ./rhash --simple empty-file.txt
00000000  empty-file.txt
./rhash --sfv empty-file.txt | tail -n1
empty-file.txt 00000000

Note that in MS Windows ending a file path with a space is considered bad (MSDN: Naming Files, Paths, and Namespaces):

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

Windows function GetFileAttributesExW and GetFileAttributesExW fail to handle such files (even with a UNC prefix).

So the problem is Linux/Unix specific. I believe it should be solved by implementing special characters support #97. As a workaround, for now you can use --magnet or --ed2k-link hash file format.

[rhash]

Implemented feature #97 has not solved the problem with spaces, since space is not considered a special character.

One possible solution is to copy behavior of GNU md5sum, which honours extra spaces in the hash file:

$ mkdir a && echo "hello world" > "a/b "
$ md5sum 'a/b ' > hash.md5
$ md5sum -c hash.md5
a/b : OK

Alternative way would be replacing any leading/ending space of a file path by the sequence "\040".

[rhash]

Leading and trailing spaces in a filename are supported by commits 9ed0a15bbbeaa4c90c56ada1fe9cf72151247218 and 25d952028ade95f7a619389fdbb1c22827511b40.

Note that, it is not recommended to use trailing spaces (or dots) in a file name on Windows. For details see the MS article Naming Files, Paths, and Namespaces.

[JensKuehnel]

Works for me. Thanks a lot. Should I wait to close it until a new release is done or close it now?