
The Fc.exe command does not work when files differ every 128th byte - tshtf
http://support.microsoft.com/kb/953929
======
DanWaterworth
I'd hate to have been the guy who discovered this. That sounds like a heap of
frustration.

------
yuvadam
I would love to see the code that produces this bug.

~~~
mseebach
Probably something like loading the 128 bytes into a byte array, then doing
something to it that requires it to be \0 terminated and then the last byte is
overwritten.

EDIT: The suggested workaround is to run it in binary mode. As binary doesn't
have a concept of \0-terminated strings, this seems to back up my theory.

~~~
pbhjpbhj
If it's something that simple then how on earth could MS ship it? What tests
would they have run that could miss this - I'd think that a test on a file
comparison program would include cycling through a single bit alteration and
checking that it was captured up to some arbitrary number of bytes (and I'd
think you'd let it run > 128 bytes too).

I'm not a coder, does this sort of assumption seem reasonable. If you can't
get the basics right ...?

~~~
Locke1689
Your test suite seems broken (which is why test suites are hard to write in
the first place). What if there is a bug when you have two bits changed -- one
in the 128th byte and one in the 256th byte? Here's a possible test suite that
could catch those bugs.

Take two files. Generate all possible combinations of byte-differences between
the two files up to a length of 256 bytes and flag invalid comparisons.

Now, what is the running time of this test case? I'll give you a hint: this
test case is unlikely to finish before the heat-death of the universe.

In general it's very hard to right comprehensive test suites and the only
thing this proves is that Microsoft developers are humans, not gods. In fact,
this is _exactly_ the type of weird corner-case bug that I would expect to
find in code written by good developers.

~~~
pzxc
He didn't suggest that the test suite should account for all possible
combinations of byte differences. He suggested that the test suite should
account for all possible combinations of SINGLE byte differences. I.E., the
test suite should have checked two files with only the first byte different,
with only the second byte different, etc. Such a test suite would be linearly
complex, not exponentially, and could easily be run before the heat death of
anything.

(However, to play my own devil's advocate, I'd have to say it's easy in
retrospect to say "yes! there is an easy test for this that should have been
written!" when in fact often the number of possible tests is astronomically
large and it can be hard to pick the right ones. What if the bug was that
FC.EXE didn't correctly register a difference when both the 127th and 128th
bytes were the only differences? The proposed test suite would not have caught
it.)

~~~
Locke1689
Your devil's advocate argument seems to be just my post. I was trying to show
that, while the parent's test suite was linear running time, the number of
tests in a comprehensive test suite is exponential, therefore the runtime of
any completely comprehensive test suite is exponential. Choosing the correct
tests to use resources on is a very difficult problem.

------
pronoiac
It sounds like it compares blocks of 128 bytes, & there's an off-by-one error
in the code.

------
quinndupont
Nothing as satisfying as really really occasional bugs. (When they aren't
yours)

~~~
Todd
At least it's reproducable...

------
joe_the_user
_"This article applies to a different operating system than the one you are
using. Article content that may not be relevant to you is disabled."_

If I don't use Windows, they hide some content.

~~~
rtaycher
I think thats just to warn vista/7 users that it doesn't effect them.

------
jodrellblank
In Windows XP, which is two generations outdated.

------
karamazov
In what kind of real-world situations would this bug impact results?

~~~
jtheory
The most common case: any situation in which only one character in a file is
different. For one in every 128 pairs of these files, more or less, fc.exe
will say "no differences found".

Are you asking why anyone would ever change only one character in a file? Typo
corrections come to mind, or mild file corruption. I recovered a ton of files
from a failing drive a few years ago, and quite a few of the text files had
just a character or two corrupted.

I'm not sure what people generally use fc for -- I don't -- so it's hard to
say how serious the impact might be when it fails.

------
CamperBob
_You must restart the computer after you apply this hotfix._

Really Microsoft?

~~~
Locke1689
This was from XP before they re-architected the DLL management. I'm not sure
blaming Microsoft for a mistake made more than 9 years ago in OS design is
relevant or helpful.

~~~
CamperBob
fc.exe doesn't use any DLLs. It's a trivial console application, deployed as a
single .exe that can be overwritten as long as it's not currently running.

~~~
Locke1689
The hotfix seems to modify ulib.dll.

~~~
CamperBob
If fc.exe depends on DLLs for its core functionality, then the whole scenario
is even goofier.

~~~
Locke1689
/usr/bin/diff depends on the following shared libraries for operation:

linux-gate.so.1 => (0xb7f31000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1
(0xb7f18000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc9000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7db0000) /lib/ld-
linux.so.2 (0xb7f32000)

Did you look any of this information up before making your statements? It
looks like ulib.dll is a DLL for file utilities, which would perform an
analogous purpose as librt and libc in any UNIX system.

~~~
quadhome
But, you don't need to reboot a Linux machine after updating a shared library.

~~~
Locke1689
_This was from XP before they re-architected the DLL management. I'm not sure
blaming Microsoft for a mistake made more than 9 years ago in OS design is
relevant or helpful._

\-- Me, about 4 comments ago

------
mdda
Microsoft's single purpose 'File-Compare' utility actually fails to do the one
thing that it was designed for? It boggles the mind. (Sorry for the lack of
content, but OMG and WTF!)

