Closed tERyceNzAchE closed 3 years ago
Let’s compute hashes of files in the current folder.
$ dirhash.exe *.*
$ dirhash *
Error: The given input file doesn't exist
Right, perhaps that would work.
$ dirhash.exe .
colorful bla-bla-bla
Blake3 (32 bytes) = D4E2853ECB998AE53763467688F403303CCBAA56CD41C78FD3488EDF2B7F264D
PRESS ENTER
Well, at least 1 hash was computed. But which one of 100? And what about 99 remaining files? Or, there is another, yet not widely known concept of “directory hash”, which should be presented first?
$ dirhash.exe . -sum
Using Blake3 to compute checksum of "." ...
AF1349B9F5F9A1A6A0404DEA36DCC9499BCB25C9ADC112B7CC9A93CAE41F3262 .\courgette.log
9839DCEF4EE3F4A30E6720F24307C0237F0B231612109D01BED6220AE282D49F .\courgette64.exe
...
Hooray, at last!
Anyway, what I have learned here is that -quiet -nowait -nologo
are obligatory switches to stay sane.
@tERyceNzAchE I have implemented relate path support through the introduction of a new switch -sumRelativePath. Version 1.19 contains this change.
@sergeevabc initially DirHash was developped to compute the hash of folder (that is a single hash value representing the content of the folder). Afterwards, SUM support was added through -sum switch. So, without -sum switch, DirHash will have its original behavior and it will output the hash value of the folder.
Full path names are stored in the results file, but the directory may be moved at some point after creation and verification will fail.
DirHash should store paths as relative to DirectoryOrFilePath.