wanttaja@ssc-vax.UUCP (Ronald J Wanttaja) (03/04/85)
<just when you thought it was safe to read net.micro.cbm again...> After a long, drawn out discussion about the infamous "save and replace" command on the 1541, the conclusion seemed to be: "It's safe, as long as there is enough space left on the disk to temporarily save the program before the earlier version is killed." After an experience I had last friday, may I politely comment, "Bullsh*t". I was using the command again, after a long lapse after being bit once, and the stupid SOB started mis-loading files, then started having serious trouble finding other ones. For instance, when I tried to load a file 4 blocks long, an entirely different one 20 blocks long came up. The directory listing showed over 200 blocks free, and I had been carefully validating the disk on a regular basis. I've heard there's some company offering a reward for disks trashed by the save/replace function; anybody have an address? Ron Wanttaja (ssc-vax!wanttaja) The difference between genius and stupidity is that genius has limits...
rfox@sdcsvax.UUCP (Richard Fox) (03/07/85)
> trouble finding other ones. For instance, when I tried to load a file > 4 blocks long, an entirely different one 20 blocks long came up. The > directory listing showed over 200 blocks free, and I had been carefully > validating the disk on a regular basis. > > Ron Wanttaja > (ssc-vax!wanttaja) > It seems that you haven't been bitten by the save replace bug but by another bug called misaligned head. The disk you are using was initialized on a drive ( could be the same one ) that was/is aligned differently and thus things like 1435 blocks free occassionly appear. I copied stuff on to a disk on a bad drive and now I sometimes trouble loading anything. Other times I get junk or 1435 free blocks. So I would reconsider your sending mail to a company about the save @ replace bug until after you are fully sure about whats happen. rich
gentner@sdcsla.UUCP (Don Gentner) (03/07/85)
> <just when you thought it was safe to read net.micro.cbm again...>
I agree with you, Ron. The three times I was bitten by save/replace
(I'm a slow learner), I was saving moderate size programs on disks that were
less than half full. There was plenty of room for temporary copies.
You say that when you tried to load a 4 block file, an entirely different
20 block file came up.
Now I predict that you first did a save/replace on your 4 block file, and
next did a save/replace on your 20 block file. Further, if you look at
your directory block, you will find that the directory entries for both
files have a pointer to the same block (the start of the 20 block file).
My guess is that for some reason, the BAM was not updated properly when you
saved the 4 block file and thus it was overwritten by the later save.
I've tried examining broken disks without getting any closer than this to
the root problem, but perhaps someone will have more luck.
Don Gentner
CSL, UC San Diego