I’m still here…
March 28th, 2010
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. 
By the way, lots of people have asked for ExactFile to scan hidden files. It’s not a “bug” that it doesn’t, but not to worry, I’ll update it so that it does scan hidden files…
Hi Brandon.
Thanks for this awesome piece of software. I know this is not a support-blog/forum but I’ll still post a question and hope for a (short) reply/hint:
Even though ExactFile has been out for a while I still like to use filecheckmd5 in certain scenarios. I’ve been using it with a new external drive lately and it seems like it gives me different results every time I run it. Sometimes “every file appears OK” then after a repeated run (with the same files) some files appear to be corrupted/changed. And every run seems to point out different files as being corrupted.
I checked the hard drive with CHDSK and SeaTools and no errors were reported. Any idea what the problem could be here?
I did not mean to pressure you into work on this, but the last comment or change I saw was over 6 months ago and I didn’t know what was going on.
Good to know you haven’t forgotten ExactFile. I hope you’ll make things like scanning hidden files an option, as I imagine some don’t need or want the functionality.
I hope some of my interface suggestions from months ago can be considered.
Cheers.
Strange. If you have any antivirus or shadow backup services running, try disabling those and see what happens.
Heh, no worries! I like working on ExactFile — but it doesn’t pay many bills so it’s pretty low on the priority list.
Hi Brandon,
thanks for replying. I don’t have any backup services running but I turned off my antivirus and made a few test runs. Again, every test run claimed different files to be corrupted. It is really strange as I’ve been using filecheckmd5 for quite some time now and never had this happen before.
I know filecheckmd5 sometimes recognizes XLS-files as changed although they are not (that happened quite a few times) but this time the claimed corrupted files are of all sorts: PDF, TXT, XML, etc.
Hi Brandon!
Have you ever compare speed of EF with other software?
Recently I made some extensive benchmarks and results show up that EF is terrribly slow.
1) In singlethread-mode it is 3-4 times (!) slower than competitors.
2) Multithread is even worse: 4 times slower than singlethread (!).
BTW: Multithread is bad idea, because HDD is bottleneck, not CPU.
Feel free to contact me for more details.
PS
Sorry for my English.
Hi,
Any chance that you can work on a portable version as well?
Glad to hear that!
I just want to say a big “thank you” for developing this great bit of software. It just saved my bacon due to corruption when copying from a usb drive.
I would never have known there was anything wrong as the large 1gb audio file played after copying but something caused a fault during the copy process.
Please keep up development! If I ever get rich ill send you money..
Works just great with Windows 7!
Multithreaded is faster than non-multithreaded in my own testing, but it will always depend on file sizes and hash methods. You should post your benchmarks on a blog somewhere so people can see what you are doing — just be sure your tests are repeatable.
If I have four 1 gigabyte files to hash with MD5, it takes 1/4 the time with four threads than it does with a single thread. HD is not the bottleneck in such a case. But if you switch to a computationally easy hash like Adler32, then that’s a different story.
The ONLY time I have seen multithreaded take *longer* than a single thread is on CD-ROM — and that’s because seek times is a bottleneck. That’s why Exactfile defaults to a single thread on CD media.
Finally, it’s pointless to use more hashing threads than you have CPU cores, so be sure you aren’t trying to hash with four threads on a single-core CPU. ExactFile defaults to using as many threads as you have cores.
Please see the TestFiles Applet function of ExactFile.