Verifying files from clipboard using certain hash does not work

[ghisler(Author)]

It only affects hashes when there is ambiguity, e.g. when the clipboard file name contains the hash, and the length is valid for multiple types. For example, a 256-bit hash (64 hexadecimal characters) is used by SHA2-256, SHA3-256 and BLAKE3, so Total Commander cannot know which of the 3 it is. Method 7 calculates all 3, but it is 3 times slower than doing just one. PreferHashType will be 0, not 2, though (I meant SHA2, not method 2).

[white]

What is the difference between

2=BLAKE3 for 256 bit, SHA2 otherwise
3=BLAKE3 for 256 bit, SHA3 otherwise

and

5=both SHA2 and BLAKE3
6=both SHA3 and BLAKE3

? Is it only the order of checking?

Why not using something like I suggested:

And it could be made an optional feature (perhaps a setting like "HashFallbackOrder=SHA256,SHA3_256,BLAKE3").

What do you think about giving the user control like this. My idea is that the user can control what happens for indistinguishable checksums by specifying one or more hash types. Then, if a user primarily uses BLAKE3, he can set it to BLAKE3 only as follows:
HashFallbackOrder=BLAKE3

I mean that the order and which hashes are checked, are specified this way by the user. Wouldn't that be more flexible?

Suppose a new hash with the same length becomes popular and is added to TC, then you need to add a lot of numbers. With my solution you would only have to add one keyword.

[ghisler(Author)]

What is the difference between

The difference is that BLAKE3 only supports 256-bit hashes. With option 2, TC will treat 256-bit hashes as BLAKE3, and all other hash lengths (e.g. 512 bit) as SHA2. With option 3, TC will also treat 256-bit hashes as BLAKE3, but all other hash lengths (e.g. 512 bit) as SHA3.

[white]

The difference is that BLAKE3 only supports 256-bit hashes. With option 2, TC will treat 256-bit hashes as BLAKE3, and all other hash lengths (e.g. 512 bit) as SHA2. With option 3, TC will also treat 256-bit hashes as BLAKE3, but all other hash lengths (e.g. 512 bit) as SHA3.

Thanks, I understand now. However, I have the following considerations:

I don't think it is easy to understand for users. The use of numbers and that a single number is used to solve the ambiguities of multiple bit lengths, is not easy to grasp.

And it's not flexible. If, for example, an improved version of BLAKE3 with the same bit length is later added to TC, you need to add a lot of numbers. And you can't specify the order in which TC should check multiple hash methods.

Whereas as something like this is very easy to read:

Code: Select all

HashFallbackOrder_224bit=SHA2,SHA3
HashFallbackOrder_256bit=SHA2,SHA3
HashFallbackOrder_384bit=SHA2,SHA3
HashFallbackOrder_512bit=BLAKE3,SHA2,SHA3

This can be used to specify for each bit length which hash methods to use and in which order. And it is flexible and much easier to understand for the user.
When the user wants to use only BLAKE3 for verification of a 512 bit hash and use only SHA2 in all other cases, he would specify:

Code: Select all

HashFallbackOrder_224bit=SHA2
HashFallbackOrder_256bit=SHA2
HashFallbackOrder_384bit=SHA2
HashFallbackOrder_512bit=BLAKE3

[white]

Verify using a checksum contained in the name of the file itself:
1. Place the cursor on a file whose name contains a checksum. The checksum must be separated from the rest of the name by a punctuation mark or space.
2. Start the "Verify Checksums" function. This doesn't work with BLAKE3 and SHA3 because they use the same checksum size as SHA2, so they cannot be distinguished automatically.

I was able to test this with a CRC checksum between square brackets, but not with other checksums. Can you give me an example of a filename with something other than a CRC chceksum.

[ghisler(Author)]

No, only CRC checksums are supported. It was added in 2010 by request, it's a format used in some (mostly shady) media downloads.

30.03.10 Added: CRC check: Support CRC checksums directly in the file names, in the form filename[1234ABCD].ext

[white]

No, only CRC checksums are supported. It was added in 2010 by request, it's a format used in some (mostly shady) media downloads.

Then I have no idea what your help text means:

Verify using a checksum contained in the name of the file itself:
1. Place the cursor on a file whose name contains a checksum. The checksum must be separated from the rest of the name by a punctuation mark or space.
2. Start the "Verify Checksums" function. There are checksum methods that generate the same checksum length, e.g. BLAKE3, SHA2-256 and SHA3-256. With these, you have to select the correct method in the dialog, otherwise an error will be shown. You can also use all suitable methods at the same time, but this is significantly slower.

What am I missing?

[ghisler(Author)]

Indeed that doesn't make any sense. I will change the help. No need to move this back to bug reports.

[white]

In TC 11.50b3 when verifying by using a hash found on the clipboard, a dropdown box is shown at the bottom with the used hash algorithm. I want to share an alternative design.

Instead of the dropdown box, create a button [Configure..."] which shows this dialog:

---

Hash Verification Settings

-- Clipboard Verification ------------------------------

Clipboard Hash Length: 64 characters

Enabled	Algorithm	Hash Length
[x]	BLAKE3	64
[x]	SHA256	64
[x]	SHA3_256	64

[ ] Show all algorithms
[ ] Save as default
------------------------------------------------------------

[ OK ] [ Cancel ] [ Help ]

---

"Hash Verification Settings" is the caption of the title bar.
"Clipboard Verification" is a group box name.
If the option "Show all algorithms" is enabled the table is expanded to include all hash lengths:

Enabled	Algorithm	Hash Length
[x]	CRC32	8
[x]	MD5	32
[x]	SHA1	40
[x]	SHA224	56
[x]	SHA3_224	56
[x]	BLAKE3	64
[x]	SHA256	64
[x]	SHA3_256	64
[x]	SHA384	96
[x]	SHA3_384	96
[x]	SHA512	128
[x]	SHA3_512	128

Right now the settings are stored in 2 ini settings: PreferHashType256 and PreferHashTypeOther. The whole list could be stored in 1 setting PreferHashType (alternative name: HashVerificationOrder), either by a comma separated list of keywords or a list of numbers.

I also want to share that I think the Verify Checksums window should be redesigned. I suggest to make it more like the other TC windows with buttons at the top and a panel in the middle and a status bar at the bottom and show progress in status bar and not in title bar. It could be similar to the Compare Contents window, with a Verify/Pause button at the top left, "Previous Error" and "Next Error" buttons next to it, "Only Errors" checkbox below it, "Background" and "Close" buttons at the right.

[ghisler(Author)]

I had something like this before, but it was very user-unfriendly to use. Therefore I changed it to what was suggested here in the suggestions forum.

[white]

I had something like this before, but it was very user-unfriendly to use. Therefore I changed it to what was suggested here in the suggestions forum.

Do you think that with my design and my choice of words, it still is user-unfriendly?

[ghisler(Author)]

I think it's too confusing for the user to get presented so many options. Also calculating multiple checksums at once is SLOW, so the user may prefer to change it on the fly.

[white]

I think it's too confusing for the user to get presented so many options.

You present 7 options in a dropdown box. I present mainly 3 options which can be sorted.

Also calculating multiple checksums at once is SLOW, so the user may prefer to change it on the fly.

The functionality does not change. In the example, I showed the checkboxes checked. That corresponds to your BLAKE3+SHA2+SHA3 option (except that in my design the order can be changed). Only the checkboxes of the hash types that are currently enabled would be checked.

I do agree however that the ability to change the hash type more quickly is possibly more useful. This could be solved by combining our 2 designs into 1. Instead of your dropdown box with 7 options (in case of a 256 bit hash value):
SHA2
SHA3
BLAKE3
BLAKE3+SHA2
BLAKE3+SHA3
BLAKE3+SHA2+SHA3

You could have a combobox with 4 options, 3 to quickly choose a hash type and 1 to configure settings:
SHA2
SHA3
BLAKE3
Configure

[AntonyD]

2white
perfect! I really hope the author can listen to reason and do just that!

[ghisler(Author)]

You could have a combobox with 4 options, 3 to quickly choose a hash type and 1 to configure settings:

The only advantage would be to have 4 entries instead of 7 in the combobox.
The disadvantage would be that you can no longer choose a combination with just 2 clicks.