Master 512
Forum by Robin Burton
Beebug Vol. 11 No. 6 November 1992
This month we're rounding off our look at CHKDSK by covering those facilities that we haven't examined in the past few issues. So far we've looked at the /F, /R and /V switches.
This, leaves /B, /D and /L which we'll look at this month. There's also clarification of a point from Vol.11 No.4 on which I've had a query, well more of a criticism really.
BAD SECTORS/CLUSTERS
The /B switch option of CHKDSK is more difficult to illustrate than the options we've already looked at, so I'll just explain it. /B is used (with /F to effect a fix) mainly when damage to the integrity of files is suspected or known, but it's not necessarily of the kind that's visible in a directory display. In effect /B offers a way of ensuring that all the files on a disc are intact, almost as if you loaded each of them in turn yourself. Of course, CHKDSK is much quicker and it can fix or patch some problems too if you wish.
The /B switch tells CHKDSK to examine a disc checking for bad clusters, verifying that the logical data on the disc is readable. I've used the word verifying and you might initially think that this operation is much like verifying a disc. Since there's a verify function in DISK.CMD, why does CHKDSK offer a similar facility?
The answer is, even ignoring CHKDSK's other facilities, it doesn't. This might seem like a minor point at first sight, but nothing is further from the truth; the two operations are very different. It's vital that you appreciate this if you suspect disc problems and use either CHKDSK or verify to attempt to find out if you really do have a problem. The truth is that you need both CHKDSK and verify most of the time.
In standard DOS there isn't a direct equivalent to the BBC's *VERIFY command, for which reason utilities like Pctools, Norton Utilities and others usually provide it. CHKDSK does not provide the 'missing' function, one reason being that in DOS (though not in the 512) discs are verified as they're formatted. In fact a comparison between CHKDSK /B and verify is spurious because there are major differences which you must understand if you're to use CHKDSK reliably.
POINTS TO NOTE
First, like the other CHKDSK operations, checking for bad blocks is based on the logical storage of data, not on the physical hardware format as it is in verifying. If an area of disc is faulty there are two possible results. Sometimes a fault might not matter in the short term. A disc fault obviously can corrupt files or directories, but alternatively and just as likely, a fault can be in an unused area of disc in which case, although there's a real problem, your files and directories might be completely untouched. You can even continue to use a faulty disc without trouble so long as you don't hit one of the bad disc areas, and this fact is sometimes exploited in copy protection of DOS discs.
Verifying a disc operates solely at the track and sector level. The integrity of DOS clusters, hence that of the logical data on the disc, is ignored by verifying. Of course, there are two sides to every argument. On the one hand verifying finds a physical disc error, regardless of where it occurs, so on the plus side verifying can confirm that a disc is satisfactory and fit to store data. It's important that you appreciate that CHKDSK doesn't do this or you could be risking trouble.
However, on the negative side, while verifying a disc tells you if there are problems anywhere, it won't and can't do anything about them. If a disc fails to verify the usual action is to reformat it. Whether this succeeds or not is irrelevant in context, the disc is faulty and reformatting destroys all data, including directories and files that might have been completely sound, so all in all it's not very helpful.
Also on the negative side, whether there are disc faults or not, there are two major limitations to verifying discs. First, even if a disc verifies as physically satisfactory, there's absolutely no guarantee that the files it contains are alright. For example, if you have a corrupted FAT there might be nothing at all wrong with the disc's format, but there certainly is a problem with files. Secondly, and in practical terms more of a problem, even if there are faults, verifying tells you nothing about whether or not your files are safe. Further, if some are not, you have no idea which are affected and which have escaped damage.
By contrast in CHKDSK, so long as the areas occupied by your data are alright, no error will be reported. This does of course mean that a CHKDSK run can report a disc as OK even though disc corruption lurks elsewhere and I can tell you that taking this reassurance too far has led some people into severe difficulties. The danger is in forgetting that CHKDSK doesn't verify the disc; it verifies only that the existing files and directories on the disc are alright. To check the entire disc you must also use verify. So long as you keep these points in mind you won't be misled.
That's the potential 'bad point' about CHKDSK, but don't overlook its powerful features because of that. As I said in the first CHKDSK article, it can help in what otherwise might be a disastrous situation. CHKDSK always concerns itself with the fact that sectors belong to clusters and used clusters belong to files, so if a sector is bad then so must that cluster be, hence the file that uses that cluster is damaged and CHKDSK knows this.
By backtracking from the sector number to the cluster number via the FAT, CHKDSK works out which files or directories are damaged and amends the FAT to reflect the facts. Imagine a file that occupies say, ten clusters, but the fifth cluster of the file is faulty. The result is that the whole of the file is inaccessible, because an attempt to read it normally will encounter the bad cluster and will fail.
FIXING BAD CLUSTERS
What CHKDSK can do in this situation when the /B and /F switches are used is to effect a fix to allow you to recover at least some of your data. Obviously, CHKDSK can't recover file data that has physically disappeared or that can't be read because of a CRC error or a faulty sector ID, but it can at least render the remaining data accessible.
The first action in the above example would be to mark the fourth cluster, the last cluster of the first part of the file, as the new end of file cluster, then adjust the file length recorded in the directory entry to match. This means the first part of the file can then be accessed normally using its original name. Next, since the second portion of the original file, clusters six to ten now represent a chain of loose clusters, CHKDSK can create a temporary file entry in the directory so the last five clusters of the original file can also be accessed.
Finally, in DOS, if a cluster is bad the fact can be recorded in the FAT. Since the FAT has a unique entry for every cluster faulty clusters can subsequently be avoided. In the above example the FAT entry for the cluster that was the fifth in the original file can be marked as bad, so future writes to the disc won't attempt to re-use it. In this way, since CHKDSK locates faulty clusters and takes them off the available list, you can continue to use the faulty DOS disc without reformatting after the fix if you must. What's more important is that you can use standard facilities to rename, copy or backup the recovered files prior to a permanent repair.
Although CHKDSK might make your data accessible and the disc logically sound, that's no excuse to abandon good sense. If a disc does go faulty, even if you do use CHKDSK /B to fix it, you should regard it with extreme suspicion, removing all the files to backups and reformatting as soon as possible. As usual, if the disc won't reformat immediately it should be scrapped, but at least in the meantime the bad cluster can be avoided automatically and the disc can be used with reasonable peace of mind while circumstances demand it.
For floppy discs the bad block fix facility might not seem very useful, especially if you keep good backups, but remember that for a winchester user things aren't so simple. Backing up a large winchester (both in DOS then in ADFS for the 512), reformatting it and then completely reloading it isn't an attractive proposition, and certainly isn't the sort of exercise you embark on cheerfully. The bad cluster option in CHKDSK can allow you to put off the evil day almost indefinitely, provided that you don't have a recurring hardware problem.
LINK AND DIRECTORY
The final two CHKDSK switches are much less useful to most users, since they're both used when disc damage is extremely severe. Both demand a good deal of manual disc editing, which in turn requires intimate knowledge of directory and FAT structures as well. Because of this I don't propose to go into great detail about them, although I will explain what they do.
The /D switch directs CHKDSK to read the entire disc looking for all directory clusters. These can be identified because the first byte of a subdirectory must be hexadecimal 2E, and the bytes in the cluster pointer must point to the root directory, while the second entry at byte 32 onwards must start with hex 2E2E and its cluster pointer must point to itself. These two entries are the single full stop and double full stop lines that appear as the first two entries on all subdirectory displays.
If you're slightly losing interest at this point I'm not surprised. All Digital Research has to say about it is that the /D switch "will try to locate all directories on the disc so that after a major disc corruption a sophisticated user can restore individual files and directories using a suitable disc editor". True, but not very informative.
What they mean is that when the 'loose' directory clusters are located you must read their contents' names, cluster pointers, sizes, dates, etc. in an editor, and then manually transfer all this information, one entry at a time, to a new, valid directory so that you can once more gain access to the files. The /D option therefore, would be used if you'd had a corruption that had totally destroyed the root directory and you wanted to recover the entire disc. Note, however, that (one copy of) the FAT must have remained intact, otherwise this is an impossible exercise.
I'll say even less about /L, because it's even less useful. After a major FAT corruption it attempts to rebuild the FAT. The user must first manually zero all corrupted FAT entries, which means first decoding them to see if they're sensible, deleting them if not. CHKDSK will then take whatever valid information remains in the FAT, plus the start cluster pointers from all the directory entries it can find and, by putting the two together and guessing where gaps occur, hopefully arrive at a usable FAT again. This process is rather like one of those 'join the dots' drawings, except that in this case the dots don't have numbers.
AND FINALLY
And finally, a point of clarification. You'll perhaps recall that in the last Forum, concerning the recovery of deleted root directory directories, I said that "The problem is that directory names don't (and must not) have an extension." I should have known better by now! What I should have said was "In DOS Plus 2.1 the problem is that.... etc.".
Bear in mind the title of this column is 512 FORUM, so remarks of this kind which appear to conflict with the normal rules for PCs probably do, because I'm talking about the 512. For anyone who's confused, in current versions of DOS, subdirectory names can take the form of 'NAME.EXT', so if you're running a recent version of DOS on a PC a directory name of, for example, PERSONAL.TXT is perfectly valid, and yes, I did know that. However, it isn't valid in the 512 and never will be whether we like it or not, hence the statement last month. OK now?
That's it again for another month. I'll be thinking of another topic for the next Forum, but I can tell you that we do have a bit more information on software compatibility, courtesy of two more members.