Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ptsfa!ihnp4!drutx!clive
From: clive@drutx.ATT.COM (Clive Steward)
Newsgroups: comp.sys.mac
Subject: Re: obtaining the full pathname of a file
Message-ID: <4196@drutx.ATT.COM>
Date: Thu, 11-Jun-87 14:59:30 EDT
Article-I.D.: drutx.4196
Posted: Thu Jun 11 14:59:30 1987
Date-Received: Sat, 20-Jun-87 12:43:05 EDT
References: <1345@batcomputer.tn.cornell.edu>
Organization: resident visitor
Lines: 59

in article <1345@batcomputer.tn.cornell.edu>, steig@batcomputer.tn.cornell.edu (Mark J. Steiglitz) says:
> 
> 
> I am writing a program in Lightspeed C that asks the user for a filename
> using the standard file package and then processes the text in that file
> using some of the stdio C routines.  I use fopen() to open the file.
> 
> fopen() requires the pathname of the file, but SFGetFile and SFPutFile only
> return the filename and the working directory reference number.  How do I
> obtain the pathname of the file?

Welcome to the party, Mark.  I just doped this out by fighting with
the HFS file system stuff in inside Mac IV for a whole night, and then
snooping someone elses code after all the heavy stuff got me nothing(!).

Getting the pathname is possible (LSC editor does it, if you ask), but
clearly involves traipsing the PBGetCatInfo trail.  Maybe someone who has
done this successfully would post some code; it would be enlightening for 
planning how to effectively do other things.

But apparently the real answer to your question is simple.  It means
taking Inside Mac's advice about not using full paths, but rather
depending on the working directory system.  And also believing what 
is said about playing fast and loose with vRefNums, which can actually
be either Volume or Working Directory references.

All it seems you have to do is take the vRefNum that you get back from 
SFGetFile, and feed that to SetVol before opening the name, e.g.:

    SFGetFile (SFPwhere, "\p", NULL, 1, typelist, NULL, &reply);

    if (reply.good) {

	SetVol ("\p", reply.vRefNum);    /* set Working Dir, actually */

	if ((fp = fopen (PtoCstr (reply.fname), "r - or whatever")) != NULL ) {
	    ...
	}
	...
    }

It's not Unix, but thinking of the SetVol as a kind of chdir will help.

The apparentlys and seems in the above are because the method works flawlessly
for me, except for one case.  

In a program I'm working on, I do an SFPutFile right after the above fragment.
This works fine, except, _only_ when there needs to be a disk swap to pick up 
the SFPutFile package.  Then SFPutFile becomes confused, and doesn't show 
the (proper or any) files in it's dialog.  I read in the last week a 
note that there's a bug in SFPutFile which sounds like it's probably this,
so probably there's not really any fault in the above.  (I was using system 3.2
at the time, think this is fixed in 4.1, but haven't tried to see yet).

Would someone like to elaborate about the bug, and how to get around
it (since users may not have the updated system)?


Clive Steward