Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!cbmvax!higgin
From: higgin@cbmvax.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDOS:  How to know if a file is on RAM:
Message-ID: <1395@cbmvax.cbmvax.cbm.UUCP>
Date: Wed, 11-Feb-87 14:56:00 EST
Article-I.D.: cbmvax.1395
Posted: Wed Feb 11 14:56:00 1987
Date-Received: Thu, 12-Feb-87 19:50:15 EST
References: <157@batcomputer.tn.cornell.edu>
Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom SALES)
Organization: Commodore Technology, West Chester, PA
Lines: 51
Keywords: AmigaDOS, RAM:, Lock(), ParentDir().

In article <157@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes:
$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.

What about if you're not one directory level from the root?
If you're already AT the root, or below one subdirectory, you end up
with a random number of ParentDir's to do.  Naturally you can keep doing
it until you get a FALSE (or whatever) from DOS, but the way I do it
is to compare the handler field from the lock with entries in the
device table until I get a match.  I then use the device name right out
of AmigaDOS' list.

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

Lock is returning a **BPTR** to a lock... note - 'most' (cringe) AmigaDOS
functions return BPTR's, so if you want to use their return pointer,
you must convert them to pointers to the actual structures.

Long will be fine, but not elegant.  Better is:

	extern struct FileLock *Lock();

	struct FileLock *DooDaa;
	struct FileLock *RealDooDaa;

	DooDaa = Lock(File, ACCESS_READ);
	RealDooDaa = (struct FileLock *)((long)DooDaa << 2);

Use RealDooDaa to look at the fields in the lock.

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

	Paul Higginbottom

Disclaimer: I work for Commodore, but opinions expressed are my own only.