Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.13 $; site uiucdcs.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!inuxc!pur-ee!uiucdcs!miller
From: miller@uiucdcs.UUCP
Newsgroups: net.micro.cbm
Subject: Re: 1541 reliability update - (nf)
Message-ID: <36100087@uiucdcs.UUCP>
Date: Mon, 16-Jul-84 16:07:00 EDT
Article-I.D.: uiucdcs.36100087
Posted: Mon Jul 16 16:07:00 1984
Date-Received: Wed, 18-Jul-84 01:57:06 EDT
References: <1750@iddic.UUCP>
Lines: 37
Nf-ID: #R:iddic:-175000:uiucdcs:36100087:000:2165
Nf-From: uiucdcs!miller    Jul 16 15:07:00 1984

#R:iddic:-175000:uiucdcs:36100087:000:2165
uiucdcs!miller    Jul 16 15:07:00 1984

>One other thing from Midnite GAZETTE: the service man that mentioned squeak
>problems also said that in his experience, 100% of SAVE "@:" problems were due
>to drive misalignment. I'm not so sure about this; I had it trash some of my
>files, and will not try it again.
>    Gary Hanson    Tektronix IDG

Gary is right, the service man is wrong.  The save and replace bug always
reacts the same way, something you would not expect from a variable misalign-
ment.  Furthermore, the problem does not arise in the file you are writing; it
kills an innocent file either before or immediately following it in the direc-
tory.  What happens is that it resets the track/sector bytes in an adjacent
file directory entry, so that the innocent file is lost and points to the start
of the save/replace file.  The save/replace operation requires a temporary spot
to hold the current file start location while it reclaims the old sectors for
the BAM.  When certain (unfortunately unknown) conditions arise, it uses
another file's pointer area to save these 2 bytes.  Boom, you're dead.  I have
heard rumors that the bug dates all the way back to the 4040 days, although I
can't confirm this.  I wish I knew the conditions under which it occurs so that
I could use it in other instances.  But it has killed files on me on disks of
>1 PRG, 100% Basic programs, on an aligned 1541.  So who knows?  Use it only if
you don't care about saving your files...

Here's another 1541 bug for you to chew on: when using the scratch command,
sometimes all of the sectors are not released to the BAM.  It deletes the file
properly, it just doesn't update the BAM correctly.  This causes no great
problems really, unless this happens a lot or your disk is almost full.  Then,
you may find that you have no more room on disk when you really should in
reality.  To check for this, add up the file sizes and the unused sector size.
If it doesn't add up to 664, then this has probably occured.  Fortunately, the
cure is quite simple: use the validate command and all should be set correctly
again.  (Warning: this does not apply if you have random files on the disk.)

A. Ray Miller
Univ Illinois