Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!umd5!zben
From: zben@umd5.umd.edu (Ben Cranston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Getting the full pathname?
Summary: Getting from PathRefNum to other data
Message-ID: <5470@umd5.umd.edu>
Date: 17 Oct 89 00:24:59 GMT
References: <850zebolskyd@yvax.byu.edu>
Reply-To: zben@umd5.umd.edu (Ben Cranston)
Organization: University of Maryland, College Park
Lines: 85

In article <6464@pt.cs.cmu.edu> fryd@g.gp.cs.cmu.edu (Michael Fryd) writes:
> ... any way to get the real filename and directory name for an open file.
Emphasis added                                                   ^^^^

Cleaning up my desk last week I came upon a printed listing of the attached
subroutine.  It occurs to me that this could also be an answer to the question
often asked on this forum "how can I get back to the DATA FORK of the file
in whose RESOURCE FORK the currently executing program lives?".  I guess you
could apply this routine to the current resource file path reference number
(hopefully before ever opening any OTHER resource files :-).

Extend this program to (if HFS is running) utilize the fcbDirID field which
should contain the long word directory ID of the directory in which the open
file exists, and fcbCName which contains the file name.  Please see diagram
on page IV-180 for these fields.  The program, as stands, makes use of the
fcbVPtr field which is there in both HFS and MFS FCBs.  Please note also
that the volume name is available at vcbVN in the volume control block.

* Err = GetVRefNum(PathRef, Var VolRef);
* Given a path reference number, return reference number for the volume
* on which the file resides.
*
* This code KNOWS that the path reference number is really an offset into a
* system heap block containing the File Control Blocks.  It performs a few
* sanity checks (detailed below).
*
* Examines incore FCB (II-127) and VCB (II-125).
*
GetVRefNum Entry			;
	Move.L	(A7)+,A1		; Pop return address
*
* Two sanity checks are performed on the PathRefNum.  One, the modulo residue
* should be 2 (because of the length word at the beginning).  Two, the RefNum
* should be less than the length of the FCB buffer.
*
	Move.L	#0,D1			; Clear slack bits
	Move.W	4(A7),D1		; Get PathRefNum argument
	Move.L	FCBSPtr,A0		; Get pointer to FCB block
	Move.W	FSFCBLen,D0		; HFS flag/length of entry
	BMi.S	@010			; If MFS go use constant
	DivU.W	D0,D1			; Compute mod of pointer
	Bra.S	@020			; Go check remainder
@010	;
	DivU.W	#94,D1			; MFS constant FCB size ???
@020	;
	Swap	D1			; Get remainder of division
	Sub.W	#2,D1			; Allow for length word
	BNE.S	@030			; If not zero then error
*
	Move.W	4(A7),D0		; Get PathRefNum argument
	Cmp.W	(A0),D0			; Within size of buffer?
	BHS.S	@030			; If not then error
*
* Sanity checks passed, link to FCB and VCB.
*
	Move.L	fcbVPtr(A0,D0.W),A0	; Link to volume control block
	Move.W	vcbVRefNum(A0),D0	; Get Volume RefNum
	Move.L	#0,D1			; Clear error code
	Bra.S	@040			; Return to caller
*
* Error in input PathRefNum.
*
@030	;
	Move.L	#0,D0			; Return zero to caller
	Move.W	#$FFCD,D1		; Get error code
*
@040	;
	Move.L	(A7),A0			; Get address of VRefNum argument
	Move.W	D0,(A0)			; Set vRefNum argument
	Add.W	#6,A7			; Pop arguments
	Move.W	D1,(A7)			; Set function result
	Jmp	(A1)			; Return to caller
*
	End				; GetVRefNum

I probably disassembled this from some program.  I have no idea what the #94
is all about, according to II-127 the number should be 30!!!  Could anybody
who knows the right number correct this?

It wouldn't be that hard to do this in either Pascal or C...

-- 
Sig     DS.L    ('ZBen')       ; Ben Cranston <zben@Trantor.UMD.EDU>
* Computer Science Center Network Infrastructures Group
* University of Maryland at College Park