On a Windows 95 machine with NameNumericTail turned off, WinHTTrack 3.02 (and
probably newer versions) overwrites its copy of
<http://any.web.site/any/path/abcdefghijklmnopqrstuvw.xyz> with the contents of
<http://any.web.site/any/path/abcdefgh.xyz> when it exists and is found later in
the crawl, rather than detecting the name collision and moving the file with
the long name out of the way.

(We interrupt this post for a cynicism break -

As a first timer here, I don't know whether I need to say what follows, but
I've seen enough posts like this one degenerate into flame wars elsewhere that
I feel obligated to head'em off at the pass.  My apologies to the vast
majority who are better than this, but bear with me while I take a moment to
predict and reply to some nonproductive responses, like:

- "You shouldn't still be running Windows 95, anyway."
This is an old machine that I keep running to test for backward compatibility
(yes, some people still do that) and for a few old programs that won't run
anywhere else which I can't bear to part with.

- "You shouldn't have turned NameNumericTail off, anyway."
This was necessary for at least one of the DOS programs I use, probably more.

- "Microsoft says you shouldn't have turned NameNumericTail off, anyway."
At one (brief) time, Microsoft was actually *recommending* this for backward
(DOS) compatibility, and, up until now, I've successfully worked around every
problem I've ever had with it (including Microsoft's own).

- "You shouldn't expect our program to handle your nonstandard configuration,
anyway."
As I said, at one time this wasn't nonstandard, but a little thought should
show that name collisions can happen on any dual naming system, no matter how
it's configured.  For example, trying to create the following files in a
folder in the specified order will cause a collision of some sort on most any
Windows OS:
	abcdefghijklmnopqrstuvw.xyz
	abcdef~1ijklmnopqrstuvw.xyz
	abcdefgh.xyz
	abcdef~1.xyz

We now return you to our regularly scheduled curmudgeon.)

As for fixing the problem, it seems the "does this file exist?" routine is
trying to be backward compatible, but in this case it shouldn't.  I don't know
if this is a coding problem specific to HTTrack, or inherent in the OS, but
either way it can be worked around.

What probably should happen is, when a supposedly matching file is found, a
second test should be made based on long file name only.  If they still match,
fine, but if not, the existing file should not be overwritten.  Instead, the
existing file should be renamed or moved temporarily, the new file created,
and then the existing file renamed back to what it was, thereby forcing the OS
to generate a different short file name for it.

Thank you for your help, and thank you for a great program!