fc.exe

[lovingboth]

File compare. Stolen Adapted from from Unix, it's been around since the early days of DOS. It allows you to compare two files, to see if they're identical, and if not, show the differences.

In its early days, it was ideal to see if that copy of a file onto a floppy was accurate. Now, I sometimes use it to see if the copy onto a CD-R is ok.

How do you think it - the version with Windows 2000 anyway - works? You've got two 700M byte files. How would you compare them?

Read them in small chunks, and compare those?

Or read one entire file into memory, all 700M of it... Even with over a gigabyte of RAM, that results in more hard disk activity as the memory is 'paged' to and from disk.

Yep, it's the latter. At least that's the only reason I can think of for its memory requirements slowly climbing to just over the size of the file.

Comments

Probably...

[kingginger.livejournal.com]

the coding has never been re written...

And for the fact that you could get errors checking section by section... (as then you would surely need to add in a load more code to make sure that the sections are checked correctly - byte start to byte finish).

Besides, I suppose as file sizes grow, the machines running checks like that would be able to cope with it.

Still - Must be important data!

[syllopsium.livejournal.com]

Cant say I'm surprised; there's probably more examples ('find?') if you look hard enough and probably even utilities with 64K hard limits.

[alisonw.livejournal.com]

if you just want to confirm that the two files are the same (yes/no) then don't wast time doing a compare that tells you information you aren't going to use.

If you look at a lot of downloads you see they give a MD5 hash and this is all you need to do. Compare the MD5 hashes of the source and destination files and if they are the same so are the files.

There are quite a few programmes around that do the job well; The one I use is SecExMD5+ which has a drag-and-drop interface not just a command-line one.