In the next version, please add MD5 and SHA1 amounts for folders in the file/folder overview columns.
I need to compare folders. It would save me a lot of time.
Why are there no CRC32- or CRC64- or SHA256- or SHA512-sums and other checksums for files and folders?
Please right-click to save the checksums to the file.
It is not possible to configure this. Namely what will be saved in this file:
3.1) the name of the file itself %name%.%extension%_file.%namesumm%
for example: "7zip.exe" --> "7-Zip.exe_file.txt" or "7zip_file.md5" or "7zip.exe_file.md5"
3.2) the contents of the file as a sample for all such cases:
name,
size(original),
date and time of change (dd. mm. yyyy HH:MM:SS:UUU),
"%MD5%" or "%SHA1%" or "%MD5%, and on the next line %SHA1%".
For example, DOpus will create for the file "DOpusInstall_12.18.exe" next text-file "DOpusInstall_12.18.exe_file.txt", which will contain the following text:
Name: DOpusInstall_12. 18.exe
Size: 55.2 MB (57 914 152 bytes)
Date of change: 2019.11.20 Wednesday, 06:44:32
CRC32: 5101AA0F
MD5: E6B78FEB24414681CA7F996B76354204
SHA-1: B30BDCF78EA0BF6D9996BA40318F2201CEB1065B
3.3) Format of this text file: UTF-8 without BOM or ANSI or Unicode or others
What do you mean by checksums for folders? Folders themselves have no data to checksum. We could concatenate every file in (and below?) a folder, but the result would depend on the order and be unlikely to be comparable to anything other than Opus itself.
If you want to test if two folders are the same, generating a list of checksums for all the files and then comparing the list will take the same amount of time and tell you which files are missing or different, which seems better. (Or use a comparison tool like WinMerge or Beyond Compare which are great for that kind of thing and integrate well into Opus.)
The other checksum types are available to the scripting API and you can find add-ins which add columns for them.
SHA-256 and above are so long that we don't think they're that useful in columns, but you can add them if you want; just install the add-in from the forum.
CRC isn't really a standard, since there are so many kinds, but the scripting API supports the most common ones and can be used to put the information in columns. I think the same add-in supports both, from memory.
The script API can also be used to save checksums to files, and will use the information in the file display if it has already been calculated, to save time.
By checksums is meant what the "7-zip 19.00" program implies. There is such a possibility in it. And if you are asking how I imagine counting the folder checksum, then it will be easier for you to look at the implementation of this function in the source code of the program "7-Zip 19.00" (there are 2 types of counting).
On the count of columns, this is true.
But I think this is the problem of the very current implementation of this function in DOpus.
My opinion: you incorrectly positioned the checksum display in the file line.
To be more precise, the checksum should not be displayed in the column of the file line, but under the file name.
Each file in details view there is a line.
The row has a width (depends on the columns) and a height (depends on the font).
I think we should leave the possibility of displaying the checksum in the file column for those who are comfortable with it.
But I'm not comfortable with it.
I want you to add (as a test) a checksum display under the name of each file.
In principle, it will be convenient for someone to look at the checksum not under the file name, but above the file name. And then the need for a column will disappear by itself.
Let the length of the checksum be greater than the length of the name, but it will not affect the length of the name column. Therefore, the program can safely include support for SHA-512 or Whirlpool.
This means that the height of the file line will increase by the height of the font that will display the checksum.
I also think it would be logical to add the ability to change the font parameters of the checksum (color, size, font format, etc.).
What is your use-case for this? You'd be comparing the numbers you get in Opus to what? The numbers in 7-Zip?
I suspect the numbers will be inconsistent between programs even if we dug through the 7-Zip source code and worked out the algorithm you want us to use but can't describe, since the checksum will be heavily dependent on the order the files are fed in to it (and any other data that's also fed in, e.g. file names, timestamps, attributes, or whatever else 7-Zip includes in this algorithm). The order won't be the same in one program or another, or potentially one locale vs another, unless that's also defined as part of a specification somewhere. The way Opus sorts files may not the same as the way 7-Zip sorts them, or may differ in some locales vs others. 7-Zip may (or may not) also calculate things via the order the files were added to the archive rather than any sorting of filenames. The character encodings will also play a part and could create mismatches between different software.
Looking at 7-Zip, it calculates two checksums for a folder in an archive, one for "data" and one for "data and names".
Even if we got the same number as in 7-Zip, I'm still unclear what the purpose is. Can you give examples of what it is useful for, versus other methods of comparing folders which give you much more detailed information about the differences?
What would you do if two folders were different? You'd presumably need to go inside them and work out what is different; at which point, why not just use a comparison tool or check against a .sfv file or similar? What's the intended use for the feature you're requesting? Is it something anyone else would find useful? (No one has ever asked for this before, for what it's worth; at least that I can remember.)
From what I can remember, 7-Zip's folder checksums don't feed the actual file data in again, they do a checksum of all the checksums (plus details like file names, for the "data and names" checksum). So you could, if you really want this and can work out the algorithm, probably do it using the Opus scripting API, since the API allows you to create arbitrary data in memory (e.g. a list of checksums) using the Blob object and then run a checksum on them using the FSUtil.Hash method.
I'd be strongly against that. Interwoven information is very difficult to mentally scan and parse, since each alternate row is a different type of data.
It would also make it much harder to compare two checksums, since the strings would no longer be next to each other even when sorting or grouping by checksum.
