hsgj@batcomputer.UUCP (02/11/87)
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@cornellahiggin@cbmvax.UUCP (02/11/87)
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.andy@cbmvax.UUCP (02/12/87)
In article <157@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: > In summary, is there a guaranteed way of knowing whether a >file you are examining is actually on the RAM: disk or not? The way I use is to check the fib_FileName[0] and make sure that it (the first character) is greater or equal than space. > 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. That RAM disk uses the standard file system. The system RAM disk uses its own. (gives it some extra speed) > 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. its should be a pointer to a FileLock. I'll have to check to be sure, of course. Maybe it doesn't like being tweaked. :-) >-- Dan Green -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga /or/ pyramid!amiga!andy } "Do not meddle with the affairs of wizards, for it makes them soggy and hard to light." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
cmcmanis@sun.UUCP (02/12/87)
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.
phils@tekigm2.UUCP (02/12/87)
In article <157@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: .... ><--- 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 Pardon me for shot-gunning this, but I don't have my manuals handy. Sounds to me like you're using the Manx compiler in 16 bit int mode, and not declaring that Lock() returns a pointer to a FileLock struct as: struct FileLock *Lock(); or including the 'functions.h' include file. If you don't declare the return type of a routine to be something other than an int, the compiler assumes it is indeed an int, and (on a 16 bit compiler) only uses the least significant 16 bits of the return value. But any pointer is 32 bits. Hence any pointer over 0xffff is truncated, which certainly cause a guru. (I speak from experience here 8-) ). I have pretty much universally decided to include the 'functions.h' file in any program I write, and this has eased the 16 vs. 32 bit int situation greatly. The only other major gotcha I run into otherwise is ensuring that parameters (n.b.: don't forget constants) passed to routines expecting 32 bit parameters (which includes most of the standard library functions) are cast as longs. Finally, I found out (the hard way) while playing with the sample printer drivers in the RKM that the Lattice compiler always seems to pass 32 bit parameters, even if the parameter type is declared as 'char' or 'short'. The Manx compiler assumes that parameters which are declared as 'char' or 'short' only take up 2 bytes on the stack. Well, enough of that. Hope it helps. -- ------------------------------------------------------------------------------- Phil Staub tektronix!tekigm!phils (206) 253-5634 Tektronix, Inc., ISI Engineering P.O.Box 3500, M/S C1-904, Vancouver, Washington 98668
phillip@cbmvax.UUCP (02/13/87)
> 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. The sure fire way of finding which device your dealing with is to: pid = DeviceProc("RAM:"); if(pid == (lock<<2)->fl_Task) /* I am dealing with a lock on a ram: file or directory */ ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making. /* eof */
dillon@CORY.BERKELEY.EDU.UUCP (02/16/87)
I think all you have to do is check to see if DeviceProc() (I think that's the name of the call) for RAM: is the same as for whatever filename you are checking. I don't have the manuals with me, but the call either takes an ascii name or a lock. -Matt