People have asked: no, I am not presently working on ExactFile. It does what I need, and I have been too busy with other projects to spend time advancing the feature set.
No, I will not open-source it. Two reasons: 1. I am using proprietary third party components so nothing I give you would compile for you unless you wanted to buy them. 2. Even if you did, my own private modifications to those, which I cannot legally distribute, would probably make it too hard to use.
ExactFile is being used by thousands of people and that is cool. A handful of those people have made small donations and I appreciate that. Thanks! But I do not foresee future development happening.
There is one bug a few people run into, which I am sorry I will not be fixing. If you are using file names with characters that are encoded with different normalization than what Windows does when UTF-16 is converted to UTF-8, then ExactFile will not be able to find your file when it loads the digest, and will report that it is not there, even if it is. The only reliable way to fix this would be to change the digest file format to be UTF-16 instead of UTF-8. This issue is very rare and affects very few people, but alas, it is there nonetheless. Sorry.
The “files were not found” issue in ExactFile v1.0.0.015 Beta is not rare at all. I have a big archival job of many files from HD-storage to Blu-ray M-Discs to do and sometimes I experience this problem. But now on the latest Blu-ray Disc, out of 204 files 61 were not found! I’m looking for a solution or switching to another application.
First, I created the digest (checksums.exf) on a hard-disk and ran TestFiles.exe on this hard-disk to check if the checksums of the files were the same in the checksums.exf file. The “files were not found” problem did not appear. Then I burned the Blu-ray Disc and ran the TestFiles.exe on the BD-R to recheck the checksums of the files with checksums.exf. Then the “files were not found” issue appeared.
When I byte-compare the checksums.exf from HD and BD-R with Total Commander, there are not differences. Identical files.
I’m not a programmer and I don’t understand the problem clearly. What I understand from your text is, that I have filenames with characters that are encoded with different normalization forms than what Windows uses. There are 4 different normalization forms, that replaces equivalent sequences of characters to one single code point in Unicode.
Normalization looks like it is not a problem when I check the checksums.exf file on hard-disk. It becomes a problem when I recheck the checksums.exf file on BD-R. Something happens between HD and BD-R storage. According to the Blu-ray Disc specification, Blu-ray uses UDF v2.5 and v2.6 file system for BD-R and Unicode 2.0 (UTF-8 and UTF-16E) character encoding. That’s too technical for me.
You propose the solution “The only reliable way to fix this would be to change the digest file format to be UTF-16 instead of UTF-8.” What is the best way for me to convert the checksums.exf before burning from UTF-8 to UTF-16 (tool, BOM, LR/CRLF) to avoid the “file not found” problem?
There is really nothing you can do. It would require changing how ExactFile saves the file names in the digest. As the post says, the problem is in the digest file. The fact that the files validate has nothing to do with the filenames.
Brandon, thanks for the swift answer. You wrote: “There is nothing you can do”. Before I start looking for another application, three final questions:
1. Is it possible to convert the filenames in the filesystem to a non-problematic form (get rid of the problematic characters), before Exactfile saves these filenames to the checksums.exf?
2. After creating the checksums.exf, is there a way to convert the checksums.exf to a form without the problematic characters?
3. Which Windows application do you recommended having the same functionality as Exactfile?
Brandon, are your sure it is an Exactfile problem?
Looking at a particular file “not found”: in the hard-disk folder where Exactfile made the checksums.exf, its filename is correctly displayed and correctly recorded in the checksums.exf.
When I look in the checksums.exf on the BD-R the filename is still correct, but the filename is truncated in the BD-R folder.
Exactfile does not have anything to do with BD-recording. Somewhere on its way from hard-disk to BD-R, something truncated the filename.
Correct?
1. In theory, but I can’t think of a quick way to manage that. 2. That would take some significant manual work, again, in theory. 3. I have no recommendations. This particular issue is only one I have seen in reports, not one I have experience myself. I have to actually fabricate the conditions to repeat it. I don’t use another application.
Yes. If the file system on the disc has different (truncated) names than what was recorded in the digest, it obviously won’t work, and exactfile doesn’t copy or rename files, it only makes a digest file.
How are you able to release the program for free if you use proprietary third party components?
None of the components I use have a royalty license. Obviously I cannot redistribute the source code of the components, but as with virtually all licenses of this type, there is no restriction on redistributing my compiled binaries.
besides the problem about utf 16 being changed to utf 8, are there any other bugs?
Brandon, thanks a lot for the software, which is free to use!
Does the console tool also use the proprietary third party components? If not, can it be open-sourced?
I have noticed a few other bugs as of version 1.0.0.15.
1. When you load a digest file encoded as UTF-8 with byte order mark, the BOM at the beginning is not recognized, therefore the first line is always ignored. (Workaround: place a comment or simply a line break on that position.)
2. ExactFile thinks SHA-1 hashes are MD5 when the first character of an entry’s filename is a symbol, irrespective of the digest file’s extension. Naturally, all such entries will fail the test and show up as errors. This may also occur with other hash algorithms, I haven’t checked. (Workaround: rename all such files or directories, then edit the digest file accordingly.)
3. ” ” (double space) is not recognized as a token separator on digest files, only ” *” (space plus star) is. In theory, the latter is supposed to indicate a binary file vs. a text one, but since this makes no difference whatsoever for either generating or verifying hashes, all other programs accept both. (Workaround: edit your digest file so that it uses the expected separator.)
Even if development is stopped, I thought I’d report these since in all cases it took me a while to find out what was going on 😉
Regards!
Thanks for the software
I have a quick question – is there any possibility of a very minor update to include an option to set which view is the default when opening a file in ExactFile via right-click “Open with”?
Basically I would prefer if it defaulted to “Create Digest” but currently it instead always defaults to “Test Digest”.
(ideally the best thing would be for it to default to “Create Digest” when opening files but then, when you specifically open a checksum file, it would default to the “Test Digest” view)
I have a quick question – is there any possibility of a minor setting option to set which view is the default when opening a file in ExactFile via right-click “Open with”?
Basically I would prefer if it defaulted to “Create Digest” but currently it instead always defaults to “Test Digest”.
(ideally the best thing would be for it to default to “Create Digest” when opening files but then, when you specifically open a checksum file, it would default to the “Test Digest” view)
The thing is, I’m a weirdo that’s actually running this program through WINE on Linux (albeit a “baby’s first Linux” in the form of Linux Mint) because, strangely, there’s no simple GUI program to create checksums when dealing with sub-folders, and any custom context menu entries are inaccessible. So the best solution was right-clicking on a file or folder and doing an “Open with” -> ExactFile (which works exactly like the “Open with” on Windows).
I regret that Brandon abandoned this tool which, in my opinion, is the best tool for SFV.