
Gawd, I love Windows :-)


You'll probably want to delete any damaged executables and reload them
fresh.  Data files should be examined and repaired.


You're not stupid.  Smartdrive caches things, and Windows also runs a
swap file which may contain data also.  All of this is pretty risky
stuff in a PC environment.


A reasonably accurate prediction...


Here's a brief description of how DOS stores files:

There are three pieces to a file.  The directory entry, the FAT chain,
and the data area.  You can think of these as a sheet of lined
notebook paper, a sheet of graph paper, and a stack of 3X5 cards.

The directory entry (notebook paper) holds the file name, actual size,
and first cluster number.  It also holds some other information that's not
important right now.

The File Allocation Table (FAT) chain (graph paper) tells where to find
the actual data.  Each square of graph paper holds a number.  If the
number is zero, the cluster associated with this box is available.  If it
holds a "magic" number, it is either the last piece of a file or a bad
(unuseable) spot on the disk.  Any other number tells which cluster
contains the next section of the file.

The data area (3X5 cards) is where the actual information is stored.
The data area is organized as clusters of a fixed size; storage is
doled out in "chunks" of one cluster each.  (In your case, one cluster
is 2048 bytes.)  As a cluster is filled, another is allocated.

To read a file, you first look at the directory entry to get the
starting cluster number.  Now you read the data from that cluster.
Next, look at the FAT entry for the cluster you just read.  This will
tell you the cluster number for the next chunk of the file.
Naturally, these numbers are usually sequential, but they can jump
around and even go backwards.  Continue reading, one cluster at a
time, as you walk this chain through the FAT, until you hit the marker
which says it's the last cluster in the file.

CHKDSK is the DOS utility that checks the sanity and coherence of
the directories and the FAT and can bludgeon most flaws into
submission.  It doesn't have any intelligence, so you have to
double-check anything it "fixes".

Now let's do a bit of a post-mortem:


All of these files have sizes (according to the FAT) which don't match
the size reported in their directory entries.  CHKDSK /F will alter
the directory entries to match the FAT size.  (In other words,   the
directory entry for CVPIC.EXE may say the file is 64,877 bytes long.
But CHKDSK found a FAT chain of 43 clusters attached to it.  (My numbers,
obviously, are made up.))


Disk space was found which is allocated in the FAT, but is not attached
to any directory entry.  CHKDSK /F gives you the option of converting these
"lost chains" to files.  You can then examine the files (FILE0000.CHK
through FILE0223.CHK) and rename or discard them.  Or, if you tell
CHKDSK _not_ to convert them to files, then those clusters will simply
be marked "available" in the FAT.



...


These files are both referencing the _same_ data cluster.  Obviously,
one of them (at least) must be wrong.  It's interesting to note that
C:\386SPART.PAR is your Windows swap file...

To fix this, you should copy each cross-linked file to a new name.
This will "fix" the cross-link by giving the files unique data spaces.
Now delete the cross-linked files.  Examine the copies and try to
assemble them properly.  Good luck.  (Hint:  "Missing pieces" are
likely to be found in those "lost chains" at the top...)


Your disk is pretty close to full.  This may be the actual cause of
the problem; perhaps Windows needed to expand its swapfile by an
amount which exceeded available disk space...

In any case, the short summary is that something trashed your FAT.
There are utilities that can mirror your FAT and help repair damage
after something like this, but you have to run them _before_ the
problem occurs.  Sorry.


-- 
----------------------------------------------------
Gordon S. Hlavenka           cgordon@vpnet.chi.il.us
Vote straight ticket Procrastination party Dec. 3rd!
-- 