Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!rochester!cornell!batcomputer!hsgj
From: hsgj@batcomputer.UUCP
Newsgroups: comp.sys.amiga
Subject: AmigaDOS:  How to know if a file is on RAM:
Message-ID: <157@batcomputer.tn.cornell.edu>
Date: Tue, 10-Feb-87 21:06:29 EST
Article-I.D.: batcompu.157
Posted: Tue Feb 10 21:06:29 1987
Date-Received: Thu, 12-Feb-87 03:48:50 EST
Organization: Theory Center, Cornell U., Ithaca NY
Lines: 40
Keywords: AmigaDOS, RAM:, Lock(), ParentDir().

If you have an AmigaDOS curdir = Lock(somefile) on a file in the top
directory of a disk, and then you take the newdir = ParentDir(curdir)
of this file, and then you Examine(newdir,&FileInfoBlock), then
the fib_Filename of the FileInfoBlock will contain the name of the
disk that the file is on.  For example, if you have a lock on the
System directory, and you do a ParentDir and then an Examine, you
will be able to find the name of the workbench disk from the
fib_Filename field.  This is nice.
	The problem is that this does not work for the RAM: disk.
For some reason, if you take the parentdir of a file in RAM: (in
its top directory, of course), the fib_Filename is null.  This is really
strange because the name "RAM Disk" does exist in the DeviceList.
	Why am I writing?  Well right now I am assuming that if I
find a null filename in the fib_Filename field, then I must be
dealing with the RAM: disk.  This may or may not be a safe assumption.
Another thing I noticed is that if you do an Info("RAM:") you will
find out that the unit number (eg df0 or df1 or such) is "-1".  Can
this also be relied on?
	In summary, is there a guaranteed way of knowing whether a
file you are examining is actually on the RAM: disk or not?
	I would like to point out that Perry's ASDG-RAM disk, along
with the hard disk i have, are both very well behaved in this resect.
Ie you can find out the volume name of either of these devices using
this trick.  It is only the default RAM: which fails to supply its
name if you do a ParentDir on a root file.

<--- Extra!  Second question for the price of one! --->
	Just off-hand, does anyone know if a "lock" as returned
from Lock() is either (a) a plain old "long", or (b) is really
and truly a pointer to a FileLock struct.  In my code, if I assume
its a long, all is cool.  But if I assume its a FileLock, and try
to tweak the FileLock->fl_Volume field, I get a free visit from my
significant other (eg the guru).  This leads me to believe that
Lock() is just returning a long (maybe the sector on the disk?)
but I would not mind independent verification.

-- Dan Green
-- 
ARPA:  hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu
UUCP:  ihnp4!cornell!batcomputer!hsgj   BITNET:  hsgj@cornella