manderse@orion.oac.uci.edu (Mark Andersen) (10/10/89)
I just had a very disturbing experience.
I downloaded the file ffc48.arc from the directory pd1:<msdos.calculator>
on simtel20, put it into a directory by itself on my hard disk, and
unarchived it. I RTFM'd, then ran the program ffc48-en.com. This program
claims to be a TSR four-function calculator, which sounded very useful to
me. Anyway, after doing some testing of the program, I exited, and found
a spurious directory entry in the subdirectory which should have contained
only ffc48.arc and the files extracted from it. The directory entry was
for a file called "LUME IN D", size of 1867xxxxx bytes (that's right,
>186 MB on a 32-meg partition of a 150-meg disk), date-time of 9-00-86
4:01p. This directory is on the fourth (f:) partition of my disk; I checked
the boot (c:) partition and found spurious entries there as well, some for
files and some for subdirectories. These spurious directory entries appeared
only sporadically; I could type in "dir" a number of times, and see the
spurious entries only part of the time.
After a warm boot about 45 minutes ago, the problem has not reappeared.
However, I have removed ffc48.arc, etc. from my disk, as well as another
archive file (also from pd1:<msdos.calculator>) by the same author.
Can someone tell me whether I have been terminally stupid, and now have
a virus-infected hard disk? If this is not a virus or Trojan of some sort,
what is it? Presumably Keith Petersen has the answer (I would have just
sent email to Petersen, but I don't have his address handy).
FYI, my system setup is as follows:
Compaq Deskpro 386 (16 MHz), EGA & color monitor, type 25 (150 MB) hard
disk, 3 MB RAM.
MuSh-DOS 3.20, Command Plus v3.0 in lieu of command.com, 386max.
By the way, the program ffc48-en.com had been loaded in high DOS memory
using 386max's loadhigh command.
Mark Andersen manderse@orion.cf.uci.edu
Dept. of Ecology and Evolutionary Biology
UC Irvine, Irvine, CA, 92717ben@val.uucp (Ben Thornton) (10/10/89)
manderse@orion.oac.uci.edu (Mark Andersen) writes: > Anyway, after doing some testing of the program, I exited, and found >a spurious directory entry in the subdirectory which should have contained >only ffc48.arc and the files extracted from it. The directory entry was >for a file called "LUME IN D", size of 1867xxxxx bytes (that's right, >>186 MB on a 32-meg partition of a 150-meg disk), date-time of 9-00-86 >4:01p. This directory is on the fourth (f:) partition of my disk; I checked This sounds a lot like what happens when you have a cache or ram-disk up in extended memory and it gets clobbered by some other program that doesn't know any better. The subdirectory entries that are in the cache can be modified without DOS's knowlege... a very dangerous situation. >MuSh-DOS 3.20, Command Plus v3.0 in lieu of command.com, 386max. >By the way, the program ffc48-en.com had been loaded in high DOS memory >using 386max's loadhigh command. I'd check compatibility of the loadhigh program with the calculator program or some other utility you are using. >Mark Andersen manderse@orion.cf.uci.edu >Dept. of Ecology and Evolutionary Biology >UC Irvine, Irvine, CA, 92717 -- Ben Thornton packet: WD5HLS @ KB5PM Video Associates Labs uucp: ...!cs.utexas.edu!oakhill!val!ben Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
craigb@hp-sdd.hp.com (Craig Bosworth) (10/10/89)
In article <3415@orion.cf.uci.edu> manderse@orion.oac.uci.edu (Mark Andersen) writes: >I just had a very disturbing experience. [... description of disk going funny after running a TSR in high memory with 386max loadhigh ...] I had a similar experience not too long ago. If you are using a disk cache, I think you are having the same problem I did. I didn't look into it *too* carefully, but I think you having a conflict in extended (the linear kind, not the page switched kind) memory between 386max and your disk cache. My solution was to get rid of 386max (I don't trust that damn thing). Try running the TSR again without the cache or without 386max. If that works, you're going to have to resolve the conflict manually by specifying on the command line what extended memory 386max and the disk cache can use. Hope this helps... BOS "We don' need no steenkeeng memory management!!" -- Craig Bosworth (619) 592-8609 16399 West Bernardo Drive Hewlett-Packard, San Diego Division San Diego, CA 92127-1899 UUCP : {hplabs|nosc|hpfcla|ucsd}!hp-sdd!craigb Internet : craigb%hp-sdd@hp-sde.sde.hp.com (or @nosc.mil, @ucsd.edu)
manderse@orion.oac.uci.edu (Mark Andersen) (10/10/89)
My apologies, especially to Keith Petersen and to the author of ffc, for the alarmist tone of my previous posting. It seems on reflection that I was indeed terminally stupid, but in a different way than I had thought. What apparently caused my problem was not the program ffc48-en.com, but simply the fact that I forgot to issue a "386max loadlow" command to resume loading programs in low DOS memory. The spurious directory entry "LUME IN D" is simply a substring of "VOLUME IN DRIVE --". Again, my apologies to all. sheepishly, Mark Andersen manderse@orion.cf.uci.edu Dept. of Ecology and Evolutionary Biology UC Irvine, Irvine, CA, 92717