Master 512
Forum by Robin Burton
Beebug Vol. 11 No. 3 July 1992
This month we continue with last month's topic by looking further at CHKDSK, the DOS command for checking the integrity of discs.
Last month we got as far as DOS disc organisation, some of the problems that can occur and the fact that CHKDSK might be able to recover data after certain types of disc corruption. Now we'll begin to look at the various options the program offers in these cases.
CHKDSK SWITCHES
As well as the ability to check the integrity of a disc's data (when no switches are set), plus the verbose (/V) switch option which provides a step by step display of what CHKDSK is doing as it runs, there are five more switches. These are of varying complexity in what they do and each of them might prove useful in certain circumstances.
The switch settings (except /V, mentioned last month) are shown below with a brief explanation of their meaning. Some are for more immediately obvious purposes than others, but unfortunately in spite of this the Digital Research DOS Plus User's Guide doesn't offer much illumination for the more obscure functions. It seems the author assumed that either you'd already know how to use the options, or you're one of those people who doesn't need or want to know.
This leaves most users with the classic 'chicken and egg' paradox. How do you to start to use something for the first time if you're supposed to know about it before you use it and the manual doesn't explain? I don't subscribe to that approach, so we'll examine each of the CHKDSK options in detail.
However, I should warn you that if you need to use some of these functions you may also have to be prepared to do a bit of disc editing during the process. Here are the remaining switches, with a brief description of their functions:
| /F | Fix errors | ||
| /B | Check for bad blocks | ||
| /D | Locate directories | ||
| /L | Link clusters | ||
| /R | Recover root directory directories |
INITIAL CONSIDERATIONS
Before we examine the switches though, I must make another point. When you embark on any sort of fix to a damaged disc, it's presumably implicit that you don't have a reliable backup, otherwise you wouldn't need to be doing it.
That being the case, you should always take a copy of the faulty disc if you can. It might seem odd to suggest backing up a corrupted disc, but doing so is the only way to ensure that you can get back to a known situation if something goes disastrously wrong during the fix process. Without this safety net you might very well end up in a worse position than that you started from.
For example, if you're using DOS floppies you might be able to use the DISK command to copy the whole disc, including the errors, to a new disc before you proceed. If it's a 640K disc you can alternatively use ADFS facilities instead if you prefer. However, neither of these options will work if the problem is a bad sector or a bad track rather than a logically corrupted FAT or directory.
In the case of physical rather than logical disc corruption, such as a missing sector or a CRC error, your choices are more limited, but there might still be a few options. You could use a BBC program like ACP's Advanced Disc Investigator ROM to make an exact duplicate of the disc (including bad sectors/tracks) if you have such software.
You might even be able to fix some errors, like CRC problems or missing sectors, with such tools, as I have done several times. If this sort of approach isn't open to you all you can do is recover whatever files you can read, cross your fingers and hope for the best (at the same time taking an oath to maintain better backups in future).
For winchester users, copying an entire disc is obviously not an option, but if damage is limited you might still be able to save some of the files before you start. It should go without saying that if you have good up-to-date backups of all your files you can avoid most of this sort of trouble in the first place, but unfortunately good backups don't necessarily guarantee complete protection against all problems.
If you're a frequent 512 user like me, the 'Law of Sod' will inevitably take over at some point; you know the one – "anything that can go wrong eventually will". When it does, the new file you've just been working on will be the one that's lost. This has happened to me on more than one occasion and, being unaware of any problem after a seemingly normal save when finishing work, I've even taken a backup, also apparently completely successfully, and then switched the machine off.
Everything seems fine and most of the time it is, but on a few occasions I've found that the next time the 512 is switched on, my original new file is corrupted. What's worse, since the backup file is a faithful copy, it is a perfect copy of a corrupted file and is therefore useless. Obviously, although the file save seemed normal at the time, it wasn't. This is where CHKDSK might be your only salvation.
FIX ERRORS
The first switch in the list, /F, can be appended to any CHKDSK command in the way shown for the /V switch last month. /F is usually used after you've established the nature of a disc problem and you've decided that CHKDSK is an appropriate way to try to fix it, perhaps after some manual editing too.
In other words, the /F switch tells CHKDSK to try to fix the trouble it finds, but as mentioned last month, if you don't supply the /F switch, even if disc errors are found by CHKDSK it won't update the disc.
This can cause a moment's panic for new users. If it finds errors CHKDSK always tells you (if the /F switch wasn't specified), but it still asks if you'd like the faults corrected anyway, even if the /F switch wasn't set. It's a simple 'Y/N' choice, but the worrying part is that it looks at first sight as if the disc might be updated whether you asked for it or not. In fact you can relax, as without the /F switch no update takes place no matter what, so I regard this unnecessary question as a bug. Without the /F switch the question shouldn't be asked, but as you can see in our first example below, it is.
To demonstrate CHKDSK I created a 360K disc containing three example files, FILE1, FILE2 and FILE3, in a single subdirectory called SUBDIR1 (great names, huh!). I've used this disc as the basis for the examples since a bigger disc, more files or more directories would produce too lengthy a display.
For each fault I then manually corrupted the FAT and the directory in various ways to show several of the most common errors CHKDSK is likely to report.
LOST CLUSTERS
The first example shows the CHKDSK report after FILE3's directory entry was deleted, simply by editing E5h (i.e. E5 in hex) into the first character of its name in the subdirectory. This, so far as DOS is concerned, means that the file entry is gone, but the occupied clusters in the FAT remain allocated although they don't 'belong' to any file. This is the sort of thing that could result from a failure during copying or writing a new file.
The situation is referred to either as lost clusters, since nothing points to or owns the clusters but they're not free, or alternatively it's sometimes called loose clusters, because there are allocated clusters in the FAT but they don't belong anywhere. Which name you prefer depends on which way you look at it, but the two mean the same.
This situation can occur when there's a power glitch or failure during a disc update after writing the data and rewriting the FAT, but before updating the directory concerned. In this case the FAT and the directory will obviously not agree. The initial CHKDSK report for our example looks like this:
Errors found, F parameter not specified. 4 lost clusters found in 1 chains. |
||
4,096 bytes disk space would be freed 362,496 bytes total disk space |
||
Note the prompt requiring an answer. It doesn't matter whether it's Y or N (upper or lower case) in this case, but you must reply.
If CHKDSK is now run again with the /F switch set these loose clusters will be allocated to a filename provided by CHKDSK. You can then rename, copy or load that file and hopefully rebuild your original file. The display for this is shown below:
| 4 lost clusters found in 1 chains. Convert lost chains to files (Y/N)? y |
||
| 362,496 bytes total disk space 1,024 bytes in 1 directories 8,192 bytes in 2 user files 4,096 bytes in 1 recovered files 349,184 bytes available on disk |
||
In this case we know that these four clusters (each of two 512 byte sectors) originally belonged to FILE3 which was in SUBDIR1, but CHKDSK can't be expected to know that and so the newly created file is always put into the root directory, the display for which in this case now appears as:
| Volume in drive A has no label Directory of A:\ |
||
| SUBDIR1 <DIR> FILE000B CHK 2 File(s) |
14-05-92 12:31 4096 349184 bytes free |
|
showing our original lone subdirectory and the new file created from the loose clusters. The last four hex digits in the filename change for each file created, but this isn't significant, while the extension is intended to remind you that this is a CHKDSK created file.
OTHER FACTORS
Of course it's quite possible in practice that loose clusters which originally belonged to several files will be found on a corrupted working disc. Equally, it's by no means certain that all the clusters belonging to each file will conveniently be located in a single contiguous block of clusters on the disc, nor even that all the linked clusters in a chain have remained intact either.
This is something else CHKDSK can't know about, so recovery isn't always as simple as the artificial example here. The best you can expect from CHKDSK under normal circumstances is that each single chain of linked loose clusters will produce one new temporary CHKDSK file. In consequence a very fragmented disc with a corrupt FAT repaired by CHKDSK might very possibly produce more (temporary) files than you originally started with. Of course each new CHKDSK file in that case might well be a mixture of clusters from several of your original files too, if corruption was severe. As a result, once you've made the FAT and the directories consistent using CHKDSK, the rest is up to you.
Again you should begin by backing up the disc before you try any recovery action. For text files the next step is to load each temporary file into your editor and try to identify what the file contains, sorting out the individual pieces (each a cluster full) that belonged to each original file in turn. Your aim is rebuilding your files one at a time, saving each of them to another disc as you go.
IS IT WORTH IT?
Obviously in the worst cases this can be an extremely long-winded and tedious job, especially if you have a large number of long files to rebuild, but I never promised it would easy. Regular defragmenting of discs doesn't just have implications for disc performance, it's the best guard against this situation too, so it's doubly worth carrying out the exercise from time to time.
Obviously, if you have to do it, text files are fairly easy to recover this way because you can read the data. On the other hand, program files and non-ASCII data files can't be treated like this and even after a CHKDSK repair, many such files will probably remain a lost cause.
That's not to say that CHKDSK is a waste of time in such cases; after all, the only alternative to a CHKDSK repair, if you have a corrupted FAT or directory, is reformatting the disc for floppies, or reallocating the whole DOS partition on a winchester. Both of these obliterate all the files and directories on a disc, but CHKDSK doesn't, so it still has a place even if you don't intend to recover and reconstitute files manually.
As usual at this point we're out of space, but next month we'll have a little light relief before continuing the CHKDSK story.