rhys@cs.uq.oz.au (Rhys Weatherley) (05/13/91)
Hi all! This is a little warning about what can happen to your hard drive if you terminate DOS applications using Windows 3.0 "Settings/Terminate" (sometimes you REALLY need to do this, especially when writing programs). I've found this out the hard way. If your DOS program has been writing output to a file (especially when it's creating a new file), then every block is marked as "unmoveable" while the file is being created, and the directory is not updated until the file is closed. This is pretty standard practice where two or more applications may happen to access the same file (not that I like this practice though). When you terminate the application the blocks are still left as unmoveable and the directory is not updated to point to the blocks - it usually reports a file length of 0. Such unmoveable blocks can begin to clutter up your hard drive quite quickly if you have to terminate programs often because of unforeseen crashes. I came across this last night when I redirected standard output of a program that I wrote to a file (since it was generating LOTS of output). I wasn't checking "disk full" or anything (and let's face it, who does with "printf"!) so the hard drive stopped spinning at one stage (when the partition was full) and I decided it was time to stop it - the only way was either to reboot or use "Terminate", and I prefer to terminate. When I got everything back to normal, I found that my partition was practically full (it had 11 Meg free before I ran the program), but the output file was of length 0. Using Norton's SD program to look at the block structure of the disk, I found nearly everything marked as unmoveable. Oh well, after a backup and reformat of the partition, everything is back to normal. So if you appear to be losing space on your hard drive when using Windows 3.0, this may be one of the reasons. I wouldn't be suprised if DOS does this on its own as well - if you reboot, DOS may leave some unmoveable blocks around - it may not even be a Windows 3.0 problem, but shows up more under it because you can terminate applications. Rhys. +=====================+==================================+ || Rhys Weatherley | The University of Queensland, || || rhys@cs.uq.oz.au | Australia. G'day!! || || "I'm a FAQ nut - what's your problem?" || +=====================+==================================+
gillham@andrews.edu (Andrew Gillham) (05/13/91)
Couldn't you just CHKDSK it and delete the lost cluster chain? -Andrew -- =========================================================================== Andrew Gillham Andrews University (gillham@andrews.edu)
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (05/13/91)
In article <1319@uqcspe.cs.uq.oz.au> rhys@cs.uq.oz.au writes: >Hi all! > >This is a little warning about what can happen to your hard drive if you >terminate DOS applications using Windows 3.0 "Settings/Terminate" (sometimes >you REALLY need to do this, especially when writing programs). I've found >this out the hard way. > >If your DOS program has been writing output to a file (especially when it's >creating a new file), then every block is marked as "unmoveable" while the >file is being created, and the directory is not updated until the file is >closed. This is pretty standard practice where two or more applications may >happen to access the same file (not that I like this practice though). I don't think blocks are really being marked as "unmoveable". (DOS has no way to do that. Norton may call them that, just because it doesn't understand what they're for.) I think it's just the fact that the directory isn't updated until the file is closed that's causing the trouble. The file gets recorded in the FAT but not the directory, so it takes up space without being accessible. The easy way to fix this is to run CHKDSK /F - but don't do this while multitasking! Some programs are likely to get very confused if CHKDSK cleans up their open files. It's safest to close down Windows, reboot, and run CHKDSK from plain DOS. You'll get the files back as FILEnnnn.CHK, and can probably recover their contents if you need to. Duncan Murdoch dmurdoch@watstat.waterloo.edu
) (05/13/91)
[Stories of DOS trouble after using "Terminate" option deleted]
Well, the problems described are trivial in comparison to what happened to me.
I had BRIEF and a COMMAND running, switching between the two to edit and
compile/run a C program. Well, I had to kill the DOS shell a couple of times
because the program hung. Then I started up another shell and ran CodeView
in it to debug my code. *WHAM* *BAM* It somehow violated system integrity
and Windows killed it off for me. No problem. Just pull up another DOS shell,
go back to BRIEF, make a few changes and write out my file.
Ooops.
Something, somewhere got *VERY* confused. As BRIEF wrote out my file, it
also copied the subdirectory I was working out of *ON TOP OF* the root
directory. So, I had a root directory that looked just like my /language/c
directory, and no way to access the rest of the disk. CHKDSK seemed to belive
the whole setup was kosher (SP?) and said nothing was wrong (save for a few
garbled entries in the directory).
To make a long story short, I ordered a copy of Mace Utilities, and had to
resort to the "unformat" option to recover everything. Must say, though, Mace
did a great job. I only lost 5-10 files, and I had everything else back to
normal within 1/2 hour.
Moral: When the Windows God declareth that ye exit Windows and reboot, *LISTEN*
-Chris
--
>>>> Chris Newbold <<<< * "If you fool around with a thing for very long you *
University of Rochester * will screw it up." *
Disclaimer: "All warranties expire upon payment of invoice."
ctne_ltd@uhura.cc.rochester.edu * uhura.cc.rochester.edu!ctne_ltd@uunet