carlos@io.UUCP (Carlos Smith) (12/25/87)
At a recent meeting of the BCS Amiga users group, a friend described being victimized by what he is sure is a new virus - but this one kills disks. The general symptoms he described were getting read/write errors on his disks, (As I recall, surface errors around track 40 or 41), followed by errors in validation of his disks, requesting a visit to the disk doctor. He is sure this was a virus because it started after he got a new batch of PD disks, and to eradicate it he had to go through all the motions described for wiping out the well-known SCA virus. Furthermore, he has had no problems with his drives, he knows someone else on a local BBS that described identical symptoms, and when he rebuilt his WB disk and reformatted all of his affected disks the problem disappeared. It seemed to both of us that if it were a HW problem it would not have disappeared so suddenly. Is anyone aware of any viruses other than the SCA virus, especially any which cause deliberate errors on disks? -- Carlos Smith uucp:...!harvard!umb!ileaf!carlos Bix: carlosmith
sdl@linus.UUCP (Steven D. Litvintchouk) (12/26/87)
Posting-Front-End: GNU Emacs 18.47.1 of Sun Aug 2 1987 on linus (berkeley-unix) > At a recent meeting of the BCS Amiga users group, a friend described > being victimized by what he is sure is a new virus - but this one > kills disks. > > The general symptoms he described were getting read/write errors on > his disks, (As I recall, surface errors around track 40 or 41), > followed by errors in validation of his disks, requesting a visit to > the disk doctor. He is sure this was a virus because it started after > he got a new batch of PD disks, and to eradicate it he had to go > through all the motions described for wiping out the well-known SCA > virus..... > Hmmm, I have just encountered *exactly* the same symptoms, immediately after having accessed a new batch of Fred Fish disks (# 111 - 118). In fact, disk # 111 went completely bad, also around tracks 40-41! Fred, if you're out there somewhere, have you noticed any problems with these disks? Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl
fnf@mcdsun.UUCP (Fred Fish) (12/27/87)
In article <20491@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: >Hmmm, I have just encountered *exactly* the same symptoms, immediately >after having accessed a new batch of Fred Fish disks (# 111 - 118). >In fact, disk # 111 went completely bad, also around tracks 40-41! >Fred, if you're out there somewhere, have you noticed any problems >with these disks? It has been about 3 weeks now since these disks were released, with probably several thousand copies in circulation by now. I have not seen any problems with scribbled disks, other than the typical random few that always seem to end up unreadable on delivery (typically about 1% or less). As a side note, I have noticed a slight increase in the number of bad floppies I have acquired over the last year. I generally use only bulk Sony DSDD, an lately have found a couple of disks in each batch of 400 or so, that could not be formatted on either my Amiga or my Mac. I was led to believe that there was no difference in the quality of the bulk disks over the individually packaged quantity 10 boxes, but now I'm not so sure. -Fred ><> -- # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/27/87)
In article <20491@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: >Hmmm, I have just encountered *exactly* the same symptoms, immediately >after having accessed a new batch of Fred Fish disks (# 111 - 118). >In fact, disk # 111 went completely bad, also around tracks 40-41! >Fred, if you're out there somewhere, have you noticed any problems >with these disks? Actually, trashing tracks 40/41 does not require a virus. There is a known bug with the Delay() system call that can cause disk corruption. Basically, if you call Delay() with and argument of 0, and the disk is being accessed, there is a finite chance that the disk will get zapped. Now, the most well know cause of this was ther Dillon/Drew shell program (pre version 2.06 I believe). Ok, that aside, the most common programming practice that gets people in trouble is using WaitForChar(0L) to simulate polling the console.device for status. This is common in programs like titlebar clocks that want to run in a loop but check now and then for a key press. The correct way to do this is to get VANILLAKEY or RAWKEY events in your window and handle them in the event loop. Or use WaitForChar(1L). Anyway, what were you running at the time? Something to think about. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
hull@hao.ucar.edu (Howard Hull) (12/30/87)
In article <620@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes: > In article <20491@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: > >Hmmm, I have just encountered *exactly* the same symptoms, immediately > >after having accessed a new batch of Fred Fish disks (# 111 - 118). > >In fact, disk # 111 went completely bad, also around tracks 40-41! > >Fred, if you're out there somewhere, have you noticed any problems > >with these disks? > > It has been about 3 weeks now since these disks were released, with > probably several thousand copies in circulation by now. I have not seen > any problems with scribbled disks, other than the typical random few > that always seem to end up unreadable on delivery (typically about 1% If you were multitasking at the time you started "df1:Movies/movie <whatever>", and you replaced the fish disk (that has Movies on it) with the one you were previously using, you could zorch the inserted df1: occupant. As previously reported on the net, The movie program is ill behaved on an A1000 [don't know if this is just with $C00000 memory like I have, or what], and leaves the df1: light on, indicating a problem of some sort. What's worse, the movie demos are so nifty that they could easily hold your attention away from the df1: indicator - I didn't notice it myself until the third time I ran the demo (Kahnankas). This is a good way of getting track 40 "randomly reorganized". > # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 > # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA Howard Hull hull@hao.ucar.edu