It does what I need…

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.

10 thoughts on “It does what I need…

  1. Marcel

    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?

  2. Brandon Post author

    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.

  3. Marcel

    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?

  4. Marcel

    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.


  5. Brandon Post author

    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.

  6. Brandon Post author

    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.

  7. Brandon Post author

    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.

  8. Anton

    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?

Leave a Reply

Your email address will not be published. Required fields are marked *