Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!lll-lcc!pyramid!oliveb!sun!cmcmanis
From: cmcmanis@sun.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDOS:  How to know if a file is on RAM:
Message-ID: <13148@sun.uucp>
Date: Thu, 12-Feb-87 11:42:42 EST
Article-I.D.: sun.13148
Posted: Thu Feb 12 11:42:42 1987
Date-Received: Fri, 13-Feb-87 20:55:31 EST
References: <157@batcomputer.tn.cornell.edu>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 57
Keywords: AmigaDOS, RAM:, Lock(), ParentDir().
Summary: You don't really

In a previous article, hsgj@batcomputer.tn.cornell.edu (Dan Green) writes:
> [... Nice description of one way to get the Volume name left out ...]
> 	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?

I have found that in practice neither of these can be relied on. The 
Ram disk acts like it does because is isn't a real device per se. It
is really just a handler and some fancy code. If you know the name
of a filename then prepending RAM: to it and checking for a Lock as
in 'if ((foo = Lock(fname)) != NULL) file exists on ram disk' will
check to see if it exists on the ram disk fairly cheaply.

> 	In summary, is there a guaranteed way of knowing whether a
> file you are examining is actually on the RAM: disk or not?

If you already have one Lock then comparing the Lock you got above with
the one you have (assuming you got one above) should tell you if it is
the same file. So the logic would be something like
    Get filename from existing lock.
    try to Lock(Ram:filename)
    if cant Lock file isn't on Ram: or is exclusively locked 
    else if FileLock->fl_Volume are not the same then it isn't on RAM:
    else we win and it is.

> ... It is only the default RAM: which fails to supply its
> name if you do a ParentDir on a root file.

Yes, see above.

> 
> <--- Extra!  Second question for the price of one! --->
(this one's easy)

> 	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

No, the answer is c) Lock() returns a BPTR, yes to get the actual
pointer you have to shift it left by four. Or use the macro in
<libraries/dos.h> called BADDR. So the syntax is :
	struct FileLock	*MyLock;
	MyLock = (struct FileLock *)BADDR(Lock(fname));

-- 
--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.