Master 512
Forum by Robin Burton
Beebug Vol. 11 No. 5 October 1992
After last month's brief interlude on applications compatibility we'll again turn our attention to CHKDSK, continuing from the Forum of two months ago.
We've looked at an example of how CHKDSK can recover loose clusters by creating a new directory entry for them and how this might help you to recover files or perhaps parts of files in certain circumstances. This month we look at another of CHKDSK's capabilities, but first there's a short item prompted by one member's experiences.
DOS PLUS
I mentioned again at the end of 512 Forum in the tenth anniversary issue (Vol.11 No.1) that all 512 users should now be using DOS Plus 2.1. I also gave Acorn Customer Service's address for the upgrade for any members who were still using 1.2.
One reader followed the advice, but received a reply from Acorn, without the upgrade, substantially to the effect that Customer Services didn't deal directly with customers (no comment necessary, I trust).
To cut a long story short I telephoned Acorn Customer Services and learned that they were temporarily out of stock of upgraded discs, but this would be remedied shortly. However, that wasn't the cause of the problem. Why this particular member had received such an odd and incorrect reply was unknown, since neither of us had sight of the original letter. The perplexing reply was presumably the consequence of the letter going to the wrong department, to someone who, unfortunately, didn't know and/or couldn't be bothered to find out who should have received it.
I can definitely confirm that Acorn will upgrade your DOS Plus 1.2 discs to 2.1 and it's still free of charge. In this area at least credit is due to Acorn for maintaining some support for the 512 in spite of the age of the system. I've often been quite blunt in the past in my criticism of Acorn for their lack of 512 support, but in this particular area they are to be congratulated for maintaining support long after other suppliers would have lost interest. That it's also a free service is even more remarkable.
As an example of an alternative way of doing things, on the release of Windows 3.1 in April Microsoft did offer a special upgrade price, but only to those who had purchased Windows 3.0 within the thirty days following the release of the new version. Even so it wasn't free, or even particularly cheap in the circumstances, but to add insult to injury the announcement was timed so that it didn't appear early enough for many people to become aware and to take advantage of it. Result? Pay again, in full!
All credit to Acorn then, but there are a few points that you must remember if you use the DOS Plus upgrade service. The upgrade may be free of charge to you, but it certainly isn't to Acorn. It actually costs them both in staff time and postage. Bear this in mind and try to make it easier for those who have to do the job.
First, don't ask for an upgrade unless you return an original set of four 1.2 issue discs. Acorn copy and send discs free of charge, so why should they supply free discs? Quite reasonably the rule is: no discs sent, none returned and no upgrade. Next, since they're doing you a favour don't expect a response by return of post. For cost and common sense reasons disc copying and despatch is done in small batches, as and when it is justified. There might therefore be a delay of a week or two before you get a reply.
Next, two of my own pet hates, and I know they frustrate and annoy others just as much as me. When you're giving time and effort free of charge there's nothing more infuriating than having to write out a return address label and paying for the postage too! If you can't be bothered to provide these items why should anyone else? As a matter of courtesy, when free help is sought you must supply a self-addressed label or packaging, complete with adequate return postage. I can assure you that even if it isn't used in all cases, the gesture is always appreciated.
The other point is equally frustrating for one of two reasons. A short note of polite explanation of your request is needed. Don't expect all Acorn staff who happen to open the mail (ever heard of temps?) to recognise four 512 DOS Plus 1.2 issue discs and work out by divine inspiration what they're for. They might ask someone who knows (or they might not) but they shouldn't have to do so. Make sure your package is clearly addressed to Acorn Customer Services, not to Acorn in general, ideally including mention of the 512 DOS Plus upgrade.
Equally important, don't hand write letters if your handwriting isn't clear and legible. The fact that you might be able to read it is no guarantee that anyone else can! I have a handwritten letter right now that I can't answer because I can't read it. No S.A.E. was supplied and I can't decipher the name and address (nor can anyone else I've asked) so I can't write and ask for a readable copy either. If it was you, write again, but clearly this time please!
While it's true that for genuinely personal correspondence a hand written letter is correct and a printed letter is, strictly speaking, impolite, that doesn't apply to business letters at any level. For business purposes, if you must write by hand perhaps because you have no printer, take the time to do so legibly. If you do have a printer, use it.
All these points are common sense and basic courtesy, but you'd be surprised just how often these items are overlooked. If you're looking for free help you must make it easy for the person you're asking, then you may very well get what you want. If you make it difficult don't be surprised if you don't.
As a final point, don't delay if you've been meaning to upgrade to DOS Plus 2.1 but keep putting it off. Acorn made the point that they can't provide the service for ever.
Now back to CHKDSK matters.
DIRECTORIES
Just as it's possible to lose a file from the failure of a disc write, a directory can also be lost after an update. The cause is a similar corruption to those which can affect files, although thankfully the loss of a directory is much less common.
However, countering that is the fact that losing a directory obviously can be a much more serious problem. The immediate consequence is not just that all the files in the missing directory can no longer be accessed, but also, if there were any subdirectories in the directory all the files in those are now inaccessible too.
However, as was mentioned two Forums ago, help may be available in the form of CHKDSK. It may not always be worth trying to recover individual files – that's a decision only you can make – but remember that a CHKDSK fix can be a much more attractive proposition than reformatting an entire disc, even if you simply delete all the recovered temporary files afterwards and replace them from good backups with working copies. This particularly applies to winchester users.
It's also very worthwhile to bear another important point in mind when a directory has been lost and CHKDSK might recover it. Just because the top-level directory is lost, there's no certainty that any of the sub-directories or the files it contained are affected, they could very well be perfectly OK – if only you could access them. Well, so long as the 'lost' directory was in the root you may be able to.
Using the same disc and contents as for the previous exercises, I've arranged an example to illustrate the point. All that was necessary was (manually in an editor) to delete the root directory entry for SUBDIR1, with the result that neither it, nor the files it contained can now be accessed by normal means. Check the Forum two months ago for what the disc originally contained if you missed it or have forgotten, but after this corruption the root directory display simply shows:
Volume in drive A has no label
Directory of A:\
File not found
just as if there never were any directories or files on the disc.
ALTERNATIVE METHODS
At this point you actually have two options. You could tell CHKDSK to recover files from loose clusters, as in the example two months ago, in which case it will report four loose chains on the disc, three of them being the inaccessible 'real' files from SUBDIR1, the fourth being the subdirectory itself. To illustrate, the display from a CHKDSK run with no parameters (i.e. check files) looks like this:
Errors found, F parameter not specified.
Corrections will not be written to disk.13 lost clusters found in 4 chains.
Convert lost chains to files (Y/N)? n13,312 bytes disk space would be freed
362,496 bytes total disk space
362,496 bytes available on disk
Of course, on a working disc with more files and maybe several subdirectories in a path too, if you choose this option all the recovered objects will end up in the root directory together. They'll be a mixture of files from all the subdirectories, as well as the subdirectories themselves, each of those also appearing as recovered files.
The problem with this approach is that you've then got to sort out which 'files' were really subdirectories, plus which files belonged to which (original) subdirectory as you copy them to a new disc or rename them. That might not sound too bad, but remember that none of your original filenames will be used for the recovered files, so you might have trouble identifying many of them. You can, though, identify subdirectories reasonably easily by looking at the contents, since the (old) filenames will be readable.
If the lost directory wasn't in the root this approach might be your only option, but for subdirectories lost from the root there's a better way. The /R parameter tells CHKDSK to recover only root directory subdirectories, so the subdirectory files remain untouched and keep their original names. By issuing the CHKDSK command on our faulty disc with the appropriate switches, only entries in the root that appear to be old subdirectories will be recovered. The way this works is that CHKDSK examines all deleted or otherwise invalid used root entries and reinstates only those which have the directory attribute bit set (bit four of the twelfth byte).
Note that the /F switch must be supplied if you want a fix. The command itself and its effects can be seen in the following display.
CHKDSK /R /F
13 lost clusters found in 4 chains.
Recover first level directories (Y/N)? y362,496 bytes total disk space
1,024 bytes in 1 recovered directories
349,184 bytes available on disk
As you can see, I confirmed the recovery request, and in this case a single directory was recovered, although CHKDSK clearly knew about three other loose clusters. This means that the three real files previously contained in SUBDIR1 have remained unchanged (and un-named).
Using /R means that the only recovered objects that will appear in the root directory are directory entries, hence the complication of files being mixed with directories is avoided. Naturally, at the same time the number of recovered objects is going to be far fewer anyway, another very helpful point.
However, even with /R helping, there's still a bit more work to do, as you'll see from the following DIR display. This was issued immediately after the above recovery run.
Volume in drive A has no label
Directory of A:\FILE0002 CHK <DIR>
1 File(s) 349184 bytes free
You can see that we only have one recovered object and that it's a directory. Note also that there's neither a date nor a time for the recovered object.
So far so good, but as you'll discover if you now try to access the recovered directory, for example using 'CD', all you'll get is an 'Invalid directory' message. The problem is that directory names don't (and must not) have an extension.
This means that you must now do a bit of manual disc editing, so that your recovered directory names are no more than eight characters long. Even if you don't change the names themselves, all the extension bytes in each entry (byte numbers 9 to 11) must be filled with spaces. Precisely where the root directory is on the disc depends on the disc capacity in question, for example on the 360K disc I used the first sector of the root was number five, but in an 800K disc the first root directory sector would be number two.
If you know enough about DOS discs you can work out where the root starts, but for any format you can rely on the fact that it's very near the beginning of the disc. Therefore, the easiest way to find the root, if you don't know where it is, is to start at sector zero and simply examine sectors one at a time until you find it. You can easily recognise it by the simple fact that it contains readable file or directory names.
Having found the root directory sector and searched for the name or names you need to amend, simply fill the three extension bytes with spaces. You'll find that, regardless of disc format, all DOS directory entries are always 32 bytes long. Any entry that starts with hex E5 is a deleted entry so don't touch those even if they otherwise match one of your real names – amend only those entries created by CHKDSK.
NOTE: Take great care during this operation. The byte after the third extension byte is the attribute byte and you MUST NOT change it. The most likely error of course, is that you overtype the attribute byte with a space which makes the entry into that of a normal file with the archive bit set. If you do have a slip and the attribute byte is altered, you MUST reset it to that of a directory entry, that is, it must contain the hexadecimal value 10 (decimal 16).
I duly space-filled the extension bytes of the name on our test disc and the resulting display from DIR is now:
Volume in drive A has no label
Directory of A:\FILE0002 <DIR>
1 File(s) 349184 bytes free
There's still no date or time but they aren't functional. You can also amend the directory name to something more meaningful at the same time, but that's up to you. The vital change is to the extension, so that 'CD' now selects the directory correctly. The three files (previously in SUBDIR1) therefore once again become normally accessible, as shown here.
Volume in drive A has no label
Directory of A:\FILE0002. <DIR> 21-07-92 13:11
.. <DIR> 21-07-92 13:11
FILE1 3119 21-07-92 13:11
FILE2 3119 21-07-92 13:11
FILE3 3119 21-07-92 13:11
5 File(s) 349184 bytes free
The Forum has had a bit more space this month, but once again that's all for now.
We'll round off our look at CHKDSK next month.