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.
Okay, so after a long time I am considering an update. Maybe I will finally take this out of beta.
One thing that I think is necessary is a native 64-bit version, so I can provide an Explorer shell plugin. This is no trivial matter — the code for many of the hash algorithms doesn’t compile in 64-bit architecture, so they need to be updated.
I don’t want to spend a lot of time doing that. So, reply here and let me know which hash methods you actually use. As far as I am concerned, MD5 and SHA are the only ones that actually matter.
Just in case you’re wondering…
The reason ExactFile hasn’t had an update in such a long time is that it does everything I need it to do. There are some more things I’d like to do with it, but other projects (that pay) always win out. I don’t see this changing any time soon. Enjoy it “as it is” for the time being.
My previous blog post indicated future development “soon.” I take it back. Future development “when I have time” is more like it.
I’ve been getting a lot of questions about the status of ExactFile lately.
Yes, I’m still here. No, the software isn’t abandoned. Yes, there will be more releases.
I’ve been focusing on my company’s Bible Study Software of late, so ExactFile has been on the back burner.
Not to worry, I’ll do more development on ExactFile soon.
A new build of the console application exf has been posted.
Version 184.108.40.206 (download, info) fixes problems with batch files.
Due to the way Windows handles Unicode output in consoles, exf was “terminating” batch files any time exf was called from a batch file. The only way I could find to fix this problem was to have exf revert the output mode to ANSI after the work is complete. What this means is that visually, Unicode characters in the console window will appear as boxes, but the actual data is still being written as Unicode. So, if you are redirecting output to a file, nothing is lost as the output is still UTF-8. It’s only what appears in the console window that is altered.
Anyway, this means you can now use exf properly in a batch file. Yay!
Another ExactFile update ready for download.
This update completes the Windows “open with” support.
The installer will offer to associate ExactFile with the following file extensions:
Don’t worry, you can opt not to do this. And if you uninstall (why would you?) the file assocations are removed.
Basically this means that ExactFile accepts a single command-line argument, which is expected to be a digest file. By assoicating the above extensions with ExactFile, you can simply double-click them in Windows Explorer and they’ll be validated by ExactFile. Also, the Explorer “Open With…” dialog will allow you to easily associate file extensions with ExactFile, so if you have some other extension you’re using, like maybe .crc32, it’ll work.
Technical detail: ExactFile doesn’t really care what the file extension is. A sha1sum checksum digest could be called “checksums.md5″ and ExactFile is smart enough to figure out that they are indeed sha1 sums, not md5 sums. As long as the content of the digest file matches one of the supported formats, it’ll work.
A new beta of ExactFile is available for download.
A help file has been added.
The Create TestFiles Applet function has been implemented. This update makes FileCheckMD5 completely obsolete. From the help file:
The Create TestFile Applet function makes it easy to provide a simple way for a user to test all of the files on a CD or DVD. This function creates a digest file much like the Create Digest function, but goes one step further: it also writes a small (less than 400K) “TestFiles.exe” application in the same folder. When the TestFiles applet (applet = tiny application) is executed, it automatically loads the digest file and immediately starts testing the files. The TestFiles application is multi-threaded* and responsive to user input even while scanning files on slow media and can be closed instantly if desired. TestFiles shows an easy-to-understand report (such as “Every file is ok”, etc).
The intended usage of this function is for you to build your deployment folder, then run the Create TestFile Applet function on that folder. Two files are added to the folder: TestFiles.exe and checksums.exf. The entire folder can then be burned to CD. From that point, running TestFiles automatically initiates file testing.
The TestFiles.exe application is “read only” in the sense that it cannot generate digest files. It merely reads the digest file created by ExactFile, compares the checksums to the files in the folder and subfolders, and reports.
The first public beta version of ExactFile is now available for download. For details on ExactFile, see the ExactFile home page.
This beta release is mostly functional. The file checksum, digest generation, digest testing, and hash benchmark functions are all quite usable.
The following planned major features are currently not implemented:
- Help file (not that you need one, right?)
- TestFiles Applet creation
- Windows “Open With” support
I will be updating this web site over the next few days to explain the various features of ExactFile. For now, I just wanted to get the beta posted.
Here are some screen shots:
A note to FileCheckMD5 users:
If you use FileCheckMD5’s “portable” functionality (for CDs, USB memory sticks, etc), you will want to keep FileCheckMD5 around for that purpose (until the Create TestFile Applet feature is implemented). ExactFile can generate FileCheckMD5-compatible digest files, so you can still use it to make your checkfiles. This is fairly trivial — just load up ExactFile, click the Create Digest page, and set your target folder and the digest type to fcmd5. Make sure FileCheckMD5 is in the target folder as well, and you’re good to go.
A quick update to exf today: 220.127.116.11. Mike C. reported incompatibility with exf’s sha1 output style and gnu sha1sum. I’ve changed exf to use gnu style output.
exf uses a series of regular expressions to parse input files without the user having to specify what kind of hash routine is being used, and these have been updated so that you can feed exf either gnu/linux sha1sum digests or the stripped-down Windows sha1sum digest formats. Anyway, it should “just work.”
I’ve posted an update to exf. You can download version 18.104.22.168. Here’s what’s new:
- Adjustments to file reading code.
- Fixed hidden files not getting scanned.
- Added -fp switch to include full path in digest output.
- Console output includes number of files hashed.
Work on ExactFile GUI continues…