Re: Disk drive damage continues even in Windows 2003

"Gary Chanson" <gchanson@xxxxxxxxxxxxxxxx> wrote in message
news:OLn8hsKyFHA.1148@xxxxxxxxxxxxxxxxxxxxxxx


[...]  I still wish to find out which files won't be rescued so I can back
them up from some other source instead.


   If that's what you want to do, I may be able to help.  Download my
WinTools package from http://www.mvps.org/ArcaneIncantations/wintools.htm.
In it, you'll find two programs which I wrote for just this purpose along
with a sample of how to set it up.  QBack does the file copying [...]


Thank you for recommending your Wintools package.  I downloaded it and
executed the Setup program, but cancelled the installation.  Here is a
screenshot:
http://www.geocities.jp/hitotsubishi/wintools.png

Now I will try to explain why I did not pursue this further, though when I
have time on a "crash box" I will experiment.  I thank you for your
efforts, but I do not have time at the moment to experiment and report
further beyond the following.

As background, one time I installed MSDN English-language version of
Windows 2000 on one computer, and connected it via a LAN to an ordinary
Japanese Windows 98 computer.  On the Windows 2000 computer, I opened
Windows Explorer, viewed a shared folder on the Windows 98 computer, and
copied all of the files in it to the Windows 2000 computer.  Windows 2000
wrote all of the files to its local disk, but gave them all garbage
filenames.  The result was usable technically but no human would ever
guess which file was supposed to be which.

The MSDN English-language version of Windows 2000 (and XP and 2003) have
no problem copying files with Japanese names from one folder to another on
a local disk.  For example I connected an external SCSI disk and copied
files from it to the Windows 2000 machine's internal disk and the files
were copied with their correct names.  Windows 2000 only had trouble with
filenames coming from remote machines.

So now, looking at what your tool showed, I have to guess:  will your tool
will handle filenames better than Windows 2000 did, or will your tool will
do the same thing to filenames as your tool does to the display of the
Start Menu folder name.  Now is not the time for guessing, so I cancelled
installation.

Two cardinal rules of selecting fonts are:  (1)  If you're writing the
text to be displayed, you choose a font that can display your text.  (2)
If you're not writing the text to be displayed, you ask the OS for a
suitable font for the text.  If you're calling an API or MFC method that
displays controls (e.g. a Cancel button) with text that is supplied by
Windows instead of by you, or if you're displaying text that the user
wrote (e.g. clipboard contents), of if you're displaying filenames of the
user's files, or if you're displaying the name of the Start Menu which
Windows returned to you when you correctly called an API to ask for the
name, you must let Windows suggest a font.

By the way, you and Microsoft are not the only developers who mess up on
this kind of thing.

Meanwhile my hopes (as they were) were borne out.  A new 250GB USB drive was
delivered Oct. 7.  On Oct. 8, Windows Explorer was able to copy all except
one directory and its contents, from the old drive to the new.  The one
directory which it couldn't read, I copied from a different disk instead,
and therefore seem to have rescued everything.

The next experiment was to see if CHKDSK /F could fix anything.  (I was
planning to try CHKDSK /X after that, but it turned out not to be
necessary.)  Unlike my experiences with Windows 2000 running CHKDSK during
boot and deleting a bunch of files without saying what it was deleting, when
the ordinary CHKDSK program ran under a fully booted and running Windows
2003 system, it recorded an event log (in the applications log) saying what
files it deleted.  Good news is that after deleting a damaged directory it
recovered the files that were in the directory, and it also recovered one
other damaged file.  Bad news is that it also deleted four other files where
I couldn't guess what the original filenames were or what directories they
had been in.  Odds are I can still make new backups by copying from other
locations, if I can figure out what files they were.

By the way I wasn't sure if there's a possibility of being a bad block, but
now I'm pretty sure it isn't.  CHKDSK didn't report any bad blocks, it read
whatever broken metadata the NTFS driver had written.  Also as mentioned
before I had installed Vista beta 1 in a guest machine under Virtual PC
2004, and Vista wrote an identical error in its event log about damage to
the NTFS structure in its C: drive.  The guest machine's C: drive is an
ordinary file on the real machine.  If the real disk had a bad block located
in that real file, then surely the real machine's event log would contain an
error report about a bad block.  But it doesn't, so I think Vista's NTFS
driver corrupted the structure in what it considers to be its own disk
drive, and I think Windows 2003 did the same to a real drive.

.