Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!daffy!cat51.cs.wisc.edu!pochron
From: pochron@cat51.cs.wisc.edu (David Pochron)
Newsgroups: comp.sys.amiga.misc
Subject: WARNING!  RRamDisk may be bad for your files' health!
Summary: It's losing data
Keywords: ramdisk.device RRamDisk
Message-ID: <1991May3.063511.4135@daffy.cs.wisc.edu>
Date: 3 May 91 06:35:11 GMT
Sender: news@daffy.cs.wisc.edu (The News)
Organization: U of Wisconsin CS Dept
Lines: 52


If you are using the RRamDisk.lzh file (recoverable Ramdisk that allows up
to 32 units to be mounted, version 1.1) I would suggest you do some testing:

I was doing some testing to see what memory it used when allocating and
decided to do a diskcopy to one of the units I had mounted as a virtual
floppy drive RAM disk.  When it finished, I checked all the files in the RAM
disk with FixDisk 1.2 and two of the files were trashed!  After doing some
further checking with DiskX, I discovered the ramdisk.device seems to be
consistently erasing the first track (both sides) of the virtual floppy RAM
disk space!  In other words, any files that used keys 2 through 21 were
always trashed because those tracks were getting cleared.

It didn't matter whether I used the FAST: device entry or the DISK:
device entry that came in the .lzh file mountlist - both lost data.

Varying the original mountlists that came in RRamDisk.lzh had no effect.

Doing normal file copies doesn't seem to cause a problem, but I have not
checked this thoroughly.  Only diskcopying a disk loses data.


Again, if you are using RRamDisk right now I suggest you stop what you
are doing and (please!) do some tests by doing a diskcopy from a floppy
disk you know has a file that resides partially in keys 2 - 21 and then
run a disk checker program on the Ram disk or use a disk editor to make
sure there is still information in those keys.

It could be just my system, but I doubt it...I booted clean from an
untouched Workbench 1.3.2 diskette and used its diskcopy and mount to test
things out - same effect.  My version of RRamDisk.lzh is 1.1; if there is a
later version, then this bug may not be present in it - but I haven't seen
a later version.

Since RRamDisk is hyped as "dynamic" (ie, it frees unused sectors) there may
be a bug in the routine that looks at the sector bitmap to see which sectors
are not in use.

One other thing - it seems to store a 0x00000001 in the "bitmap valid" field
of the root block instead of a -1 (0xFFFFFFFF) - FixDisk 1.2 complains about
this, and DOS always has to revalidate the RAM disk, and fixes it to a -1.


I will be switching back to VD0: and RAD: for now...A ram disk that loses
files is best not to be even touched!


-- 

          David M. Pochron   | Transparent DWV pipe:  For the man who wants to
                             |                        see it all...
pochron@garfield.cs.wisc.edu | (If you don't know what DWV is, get a life! :-)