perry@well.UUCP (Perry S. Kivolowitz) (07/17/87)
The story so far:
Hans: Perry, why does verification go faster when Facc is running?
Is it really verifying from disk?
Perry: Don't know why its running faster but it IS verifying from disk.
Hans: Ok, thanks.
Perry: With C. Scheppner's help we found out why verification runs faster.
Not to worry - it is verifying from disk.
Chapter II - The Plot Thickens...(or - as the disk turns)
I have been getting about one request a week asking if all was kosher
concerning Facc's apparent format acceleration. I kept looking for a
problem but never found evidence of one.
Well, talk about a case of blinders - I couldn't see any difficulty
in the formating because I never had a floppy that had any flaws!!!!!
Damn Sony's :-)
Anyway, I resorted to punching a hole through one of the little fellers
and lo! It didn't format anymore. Gee.
I started up FaccII and saw that the bashed sectors were in fact being
verified from disk and were being rejected as misformatted. So format
retried. And the retry came from the cache. Ooops. Sorry.
Four assembly language instructions later I can now promise that FaccII
formats correctly.
Have no fear of your formatted floppies however, the bug only manifests
itself if there have been RETRY's. If your floppy formatted cleanly then
it is a perfectly formatted floppy.
Sorry - And thanks to all on this especially Hans, and OJSands.
Perry S. Kivolowitz - ASDG Incorporatedscotty@l5comp.UUCP (Scott Turner) (07/21/87)
In article <3569@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: >Anyway, I resorted to punching a hole through one of the little fellers >and lo! It didn't format anymore. Gee. > >I started up FaccII and saw that the bashed sectors were in fact being >verified from disk and were being rejected as misformatted. So format >retried. And the retry came from the cache. Ooops. Sorry. Ooops sorry? Perry, if I understand what you just said then what is going on here has NOTHING to do with formatting disks. Rather it sounds like what you are saying is that even though trackdisk.device said the data read was bad you cached it anyway! So rather than the problem being that you were caching format data, you were instead caching data from reads that trackdisk.device said was defective? >Four assembly language instructions later I can now promise that FaccII >formats correctly. But what happens if a disk takes a hit and a file is damaged? Will emacs read the file and report nothing is amiss because facc cached it for the retry? >Have no fear of your formatted floppies however, the bug only manifests >itself if there have been RETRY's. If your floppy formatted cleanly then >it is a perfectly formatted floppy. Uh, you mean that so long as my disk had no defects on it in the first place then it isn't defective? But that if it had defects then format didn't catch them and I may be using disks that I THINK are perfect and yet are NOT? Shouldn't that paragraph read: You may want to check any floppies that were formatted with FACC enabled since the bug I fixed may have caused format to report defective disks as being non-defective. PLUS issue: Also, please be aware that if you have FACC enabled and encounter a bad block on the disk the above bug may mask this and make the block appear good. You should upgrade your FACC ASAP. [or only use Sony diskettes] Or am I wrong? Gee I wish I had a FACC so I could feed it a blank disk and see if FACC makes it appear as formatted but blank when I tried to read it! :-) Hmm, might be worth buying a FACC just to try that... Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan Disclaimer? I own L5 Computing. Isn't that enough?
perry@atux01.UUCP (Perry S. Kivolowitz) (07/22/87)
In article <300@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes: >(stuff) Scotty, Facc and FaccII provide reliable reliable reads from a floppy file system. Thanks for your interest. A more productive means of examin- ing the correctness of Facc operation would entail purchasing a copy of Facc rather than ``armchairing'' it (or in your case - ``armcharing'' :-) While your opinions and theories are most welcome (and do keep them com- ing!) they are often off the mark. This could be corrected if you had the proper materials from which to base opinion. So, rather than continue posting messages based upon what other people say about Facc, why not get the product and make informed offerings. Towards this end (and because what you have to say IS valued) why not send us (by physical mail) your address and allow us to send you a copy of Facc on us? That way you'll also have a chance to see first hand the continuing evolution of Facc (into FaccII and beyond) from a simple caching scheme into a comprehensive floppy cache manager. In summary: If we've got bugs or misfeatures in Facc, we want to know. In fact, we'll even send you copy free to help you tell us. We take responsibility for our products. If they aren't as perfect as we can make them then we want to know. (remember though that much of what was discus- sed here on usenet and other places has already been reflected in FaccII so there may not be much you can add :-) Fair Enough? Perry S. Kivolowitz ASDG Incorporated 280 River Rd Suite 54A Piscataway, N.J. 08854 or call - (201) 563-0529