compare md5 against string checksum

spring_leaf

7 years ago
updated 6 years ago
Planned

The "test" feature for copied files and the possibility to save the generated checksum file are very good, but it would be even better if TeraCopy would offer the possibility to check a file against a numeric checksum (for downloaded files, for example). Indeed, this is not complicated at all to do manually (from creating a md5 file in a text editor to using all sort of small utilities already available), but exactly because is so simple, it should be implemented as a feature.

How I see it working:

Right click on the file: Windows Shell Context menu (or Submenu) "Check MD5" -> will open TeraCopy interface with a field that prompts for MD5 string value.

Benefits: - the most important benefit is to reduce "manual labor", after all this is the purpose of computers and software.

Where it would be useful:

- when downloading files from locations that offer the MD5 checksum for the file as a text, instead of a .md5 file, in order to ensure the download was complete and without issues.

Replies 6

Newest first
Newest first Oldest first

7 years ago

As you can see in the attached image, the File List has not been expanded, so assuming there would be a hint present there, it cannot be seen. Still, I was able to check the file against the hash in my clipboard.

Displaying the hint after testing a file is pointless as the purpose of the hint is to give information before doing the action, not once the action failed.

The whole purpose of doing a graphical interface for a program is to make the use of it more seamless, faster, not more intricate. For direct commands, there is always the terminal... whoever doesn't need visual helpers can use command line.

Anyway, I tried to explain this from the point of view of an inexperienced user, as you may want to aim your software towards anyone wishes to use it not only power users. So, consider this:
- user does RightClick -> TeraCopy, on a file, or drag-and-drop the file in TeraCopy window
- Test button appears
- User clicks Test and what TeraCopy will do it is to create a md5 file (not what the user thought it will happen)

Now, let's see how this can be improved:
- user loads file in TeraCopy (right-click -> TeraCopy, or drag-and-drop)
- Instead of Test, a "Generate Hash" button, which is more suggestive: it will generate a hash based on current state of the file.
- A Second button named "Test" (or whatever you think is best) would compare the file against the hash. - Now, I understand here would be a redundancy, as the hash has to be generated before comparing, reason why you probably made one button with dual functionality. But think from user point of view: users are not as efficient as programmers and machines.
So, this "test" button would need to do a smart thing when pressed:
- check if a hash string has been copied in the clipboard
- if there is something copied in clipboard, check if indeed is a md5 hash and not a cookies recipe (check the string structure, if is indeed a 128bit hash hex string). This is important to not run a pointless check. Better warn the user before wasting time. Anyway, I believe you are already doing the string check.
- if there isn't a valid hash in the clipboard, it should give a warning. But only if there isn't! Having the screen occupied with pointless information is equally bad like not providing it when needed.

Most of users understand what "clipboard" means and how to copy something in the clipboard, but there are users that may not know... don't be surprised, I met educated people that lacked some basic computer-related knowledge. So, for this reason, I would suggest TeraCopy to provide an input field for a hash string if it hasn't been copied in the clipboard. Yes, it may seem redundant again (because for the user to paste it in the input field, it has to copy it first, which already solves your problem), but you are different, you think in more abstract patterns than many users. So, having a field that asks for the string may be more descriptive for them.
Of course, a simpler way would be just a Warning Dialog saying "copy a hash string in the Clipboard" and that's it... who can't get it around, is their problem. And I would be happy with that too. What I would like you to understand, is the importance of the following:

1. dedicated button for generating hash
2. dedicated button for comparing against a (clipboard) hash
3. warning if user tries to compare without having a hash copied

Reply Link

Code Sector

"The user will be required to have the files list open" - how else the user will see the calculated checksum? The hint will be displayed only after testing a single file.

If you are doing it like this, there will be two downsides:
1. the user will be required to have the files list open (which most of the time I prefer to keep collapsed)
2. if the files list will be open by default, so the user can see the hint, it will occupy unnecessary large area on the screen. I see no point why a copy operation would occupy one quarter of my screen, just to display a hint.

Renaming the initial button to "Save Hash" made it intuitive (it tells the user what the button does), but only in the condition where is no existing hash to compare against. This is why the initial idea suggested two buttons, each clearly stating their purpose: one for testing against a existing checksum and another one to generate a checksum based on file.

As for the hint, it would be enough a warning dialog to inform the user to copy a hash, in my opinion. It is possible the user will get used to the workflow after few warnings and from that point will copy the hash before doing any operation. So, in this case, the permanently visible hint will become obsolete. Probably it would be best to follow the user's habit, rather than to force the user into a habit. Always software that tried to force different habits in users without good reasons, eventually failed, because the market is full with all sort of programs, each developer thinking in their own way... but only the most intuitive and user-friendly survive, eventually.

7 years ago
Planned

We will add a few hints like this:

Yes, "something like this" - but as this feature wasn't very "obvious". Until you shown this example, I wasn't even aware it existed. Maybe is should be presented different to the user.
The most important rule in designing a software (or anything) is to not rely on the user to remember hidden functionalities. Best is the interface to be as much as possible self-explanatory. Of course, there are conventions that became common knowledge when comes to using computers, but any special feature should be easier for the user to find.

Suggestion:

Test button to ask from the user to copy a checksum in clipboard (or to present a input field for it), if it hasn't been already copied.
As for generating a new hash file (which the Test button does now, if ran against a file with no hash to compare), a new button should be added for doing just that.

Reason for the above:

- although the current configuration offers the requested functionality, it is hidden and non-intuitive (proof that I didn't even know it existed)
- current configuration requires a learning curve, as multiple results can be achieved with the same command, so the user needs to make supplementary checks in order to obtain the desired result (to make sure he already copied a hash string in clipboard, or else the app won't prompt for it and instead will deliver a different result: will test a file and generate a new hash, instead of comparing)
- the interface will not suffer by adding a new button, there is place and it would be beneficial for most of the users which are not very familiar with the feature.

7 years ago
Under review

Something like this?