9737

神经网络昆斯林的新闻组分类2006

Xref: cantaloupe.srv.cs.cmu.edu comp.os.ms-windows.misc:9737 comp.os.msdos.programmer:23233
Newsgroups: comp.os.ms-windows.misc,comp.os.msdos.programmer,uiuc.sys.ibm-pc
Path: cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!udel!news.intercon.com!psinntp!laidbak!tellab5!vpnet!cgordon
From: [e-mail] (gordon hlavenka)
Subject: Re: Save my hard disk?!  (allocation error, cross-linked)
Message-ID: <[e-mail]>
Organization: Vpnet Public Access
References: <[e-mail]>
Date: Wed, 21 Apr 1993 03:36:15 GMT
Lines: 137



 Brad Banko writes:
>While running the MS Quick C compiler in a DOS window under Windows 3.1 
>this evening, I got a "program has violated system integrity... close all 
>applications, exit windows and restart your computer" error.

Gawd, I love Windows :-)

>1)  Is there an easy way to restore everything to working order?
>What might be some better approaches?

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

>2)  What might have caused this?  Does the SMARTDRV cache make me more
>vulnerable?  (I'm suspicious of hard drive caches especially when they
>cache data writing.)

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.

>The straightforward approach would be to run chkdsk with the /f option to 
>fix the disk and then it looks like I would probably have to reinstall Windows
>and a few other things.

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:

>C:\GFX\VPIC46\CVPIC.EXE
>C:\GFX\VPIC46\VPIC.TXT
>C:\GFX\VPIC46\VIDEO7.CFG
>C:\GFX\VPIC46\ORCPRO2.CFG
>C:\GFX\VPIC46\VGA.CFG
>C:\GAME\GOOSE\BIRD2.X
>C:\WINMISC\ADV21\WINADV.EXE
>   Allocation error, size adjusted

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.))

>   316 lost allocation units found in 224 chains.
>    647168 bytes disk space would be freed

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.


>C:\GFX\VPIC46\CVPIC.EXE
>   Is cross linked on allocation unit 16133

...

>C:\386SPART.PAR
>   Is cross linked on allocation unit 16133

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...)

>  42366976 bytes total disk space
>   3958784 bytes in 4 hidden files
>    153600 bytes in 67 directories
>  36042752 bytes in 1496 user files
>   1564672 bytes available on disk

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           [e-mail]
Vote straight ticket Procrastination party Dec. 3rd!
-- 
----------------------------------------------------
Gordon S. Hlavenka           [e-mail]
Vote straight ticket Procrastination party Dec. 3rd!