Related Info: File Manager Standard File

XCMD Corner: HFS Tree Climbing

By Donald Koscheka, Arthur Young & Co., MacTutor Contributing Editor

Hyper Lite

In keeping with the spirit of the summer season, this month’s XCMD is light and easy. Not too long ago, I promised to provide an XCMD that, given the name and directory id of a file, returned that file’s full pathname. Such a utility is eminently useful in the current incantation of Hypercard.

Hypercard is fully capable of opening a file, reading and writing its contents and then closing the file. Unfortunately, unless you know the full path name of the file, you are limited to accessing files in Hypercard’s working directory.

One of the first published XCMDs was a little gem from Steve Maller of Apple Computer Inc. that eliminates this MSDOS-compatible feature of Hypercard. Steve’s FileName.p presents the user with the standard file package and returns the full pathname of the file specified.

If you are a regular reader of this column, you’ll recall that I translated Steve’s XCMD from pascal to “C”. You also know that my version lost something in the translation. Rather than return a full pathname, GetFileName.c returns the file’s name and working directory id. I felt this was more useful because the file’s name and wdid open up access to most of the file manager calls for the XCMD programmer. Still, if you want to continue to use Hypercard’s built-in file I/O, getfileName won’t be of much use since it doesn’t return the full pathname required by hypercard.

Listing 1 (FullPathName.c) is a simple XCMD that accepts the filename and working directory id as input and returns the fullpathname of the file as output.

As is often the case, this XCMD first converts the input data from c-string format to pascal strings and numbers as needed. Note that the default return value will be the name of the file that was passed in param[0].

A Review of HFS

As a rule, we don’t come into contact with full pathnames very often on the Macintosh so the format may require a little explaining. If you want to explore the Hierarchical File System in greater detail, take the time to read Chapter 19 of volume IV of Inside Macintosh. If you don’t have volume IV handy, the following discussion will get help you understand the code.

Devices that can store and retrieve data on the Macintosh are called “volumes”. Files are organized on volumes in folders. Folders can contain other folders yielding a hierarchical or “Tree structure”. The order in which folders are stored in this tree structure specify a path to any file that is contained in that folder.

The root of this tree is the volume name. If we stick a “:” onto the end of the volume name, we have the beginning of a full pathname. In other words full pathnames always start with the volume name. Each path in the pathname is delineated by the “:”. Thus, Hd:folder:file specifies a valid pathname. The last item in the pathname is the name of the file itself. The folder that holds this file is referred to by a unique directory id. When the user selects a file using SFGetFile or SFPutFile, the file manager returns the file’s name as well as the directory id. For historical purposes, the directory id is stored in the vRefNum field of the reply record. This little tweak is how Apple was able to make HFS backward compatible with the flat-file system.

Tree Climbing

The folder that contains the file represents the deepest node on the tree. The next folder up the hierarchy is called the parent. Knowing the parent’s id, we can call PBGetCatInfo to get its name as well as the directory id of its parent folder. We climb the tree by continuously feeding a parent directory id into PBGetCatInfo until we detect an error (no more folders on this path).

Tree climbing suggests recursion. The routine ClimbTree in Listing 1 calls PBGetCatInfo to get information about the directory whose id was passed in. We kick it off by first getting information about the folder that holds the file. This is the directory whose id was returned in the reply record.

Each activation of climbTree uses the same catalog parameter block (cpb) which was allocated in the stack frame of FullPathName. This is legal because the only information that is unique to each activation is the directory id (passed as a parameter in child) as well as a pointer to the string the PBGetCatInfo uses to store the folder’s name. Each activation allocates memory for the name string and sets cpb’s ioNamePtr field to point to its own copy of the string.

I allocate the string, folder_name, in the heap and point to it on the stack because successful recursion dictates that one be mindful of the stack at all times. Even if there is no danger of overflowing the stack, a little defensive programming goes a long way.

A nice feature of the recursion is that we can build the string in forward order. Although we walked the tree backwards, we don’t actually put the full pathname together until we reach the root which is detected by discovering that it has no parent folder. Once we reach the root, the stack unwinds in the order of root->parent->child->filename.

The following script, working with GetFileName.c (See Mactutor Vol. 5 No. 6) returns the full pathname of a file selected via standard dialog:

--1

on mouseup
 put getfilenametoOpen() into it
 if item 1 of it is not empty then
 put Fullpathname(item 1 of it, item 2 of it) into it
  end if
end mouseup

Because Hierarchical File System can’t handle pathnames longer than 256 characters, I limit the string returned by Fullpathname to 256 characters. If you want to return the full path regardless of length, you can modify the concat routine in “HyperUtils.c” to “grow” the output string on demand.

Listing:  FullPathName.c
/********************************/
/* File: FullPathName.c   */
/* Given the name and working */
/* directory of a file, walk the*/
/* directory tree to determine*/
/* what the full pathname of the*/
/* directory is... */
/* Paramters:    */
/* param0 = file namenum  */
/* param1 = directory id  */
/* Out: */
/* full pathname of the working  */
/* directory   */
/* Once again, I am indepbted to*/
/* Steve Maller of Apple  */
/* Computer Inc for illuminating*/
/* this oft too dark realm of */
/* the toolbox.  */
/********************************/
#include<MacTypes.h>
#include<OSUtil.h>
#include<MemoryMgr.h>
#include<FileMgr.h>
#include<ResourceMgr.h>
#include<pascal.h>
#include<strings.h>
#include<hfs.h>
#include  “HyperXCmd.h”
#include“HyperUtils.h”
#define nil 0L

char    colon[2] = “\p:”;

void ClimbTree( child, cpb, fullName )
 long   child;
 CInfoPBPtr cpb;
 char   *fullName;
/*************************
* Climb the directory tree
* until we reach the root
* Allocate the records in the
* heap to keep the stack frame
* as small as necessary.  Too
* large a stack frame can 
* lead to a case of terminal
* terminal.
* child is the working directory
* id of the “current folder”, vol
* is the volume reference number and
* fullName points to the 
* output string
*************************/
{
 StringPtrfolder_name= (StringPtr)NewPtr( 256 );
/*** setting the file directory index to -1***/
/*** lets us get information about the ***/
/*** directory whose id is specified inthe***/
/*** ioDrDIrID field of the parameter block***/
 folder_name[0] = ‘\0’; 
 cpb->dirInfo.ioNamePtr   = (StringPtr)folder_name;
 cpb->dirInfo.ioDrDirID   = child; 

 if( PBGetCatInfo( cpb, 0) == noErr ){
 ClimbTree(cpb->dirInfo.ioDrParID,cpb,fullName);

 Concat( (char *)fullName, (char *)folder_name );
 Concat( (char *)fullName, (char *)&colon );
 }
 DisposPtr( folder_name   );
 
}

pascal void main( paramPtr )
 XCmdBlockPtr  paramPtr;
{
 Str31  str,fName;
 short  wdid;
 WDPBRectheWDPB;
 CInfoPBRec theCPB;
 HParamBlockRec  theHPB;
 char   fullPath[256];
 char   part_Name[256]; /*** used in HPB     ***/
 char   vol_Name[256];
 OSErr  err;

 colon[0] = 1;
 colon[1] = ‘:’;
 
 vol_Name[0] = ‘\0’;
 part_Name[0]= ‘\0’;
 /*** empty is the default answer ***/
 paramPtr->returnValue = 0L;

 HLock( paramPtr->params[0] );
 ZeroToPas( paramPtr, *(paramPtr->params[0]), &fName );
 HUnlock( paramPtr->params[0] );
 
 /*** convert the wdid to a usable form ***/
 HLock( paramPtr->params[1] );
 ZeroToPas( paramPtr, *(paramPtr->params[1]), &str );
 HUnlock( paramPtr->params[1] );
 wdid = StrToNum( paramPtr, &str );
 
 /*** First, we appeal to GetVInfo to get    ***/
 /*** volume name that the file lives on     ***/
 part_Name[0]    = ‘\0’;  
 theHPB.volumeParam.ioNamePtr = (StringPtr)vol_Name;     
 theHPB.volumeParam.ioVRefNum = (short)wdid;             
 theHPB.volumeParam.ioVolIndex   = 0;  
 if(PBHGetVInfo( &theHPB, 0) != noErr )
 return;  

 /*** Next, use the working directory info   ***/
 /*** to walk the directory tree backwards   ***/
 /*** to the root directory ***/
 theWDPB.ioNamePtr = (StringPtr)part_Name;
 theWDPB.ioVRefNum = wdid;  
 theWDPB.ioWDProcID= 0;   
 theWDPB.ioWDIndex = 0;   
 if( PBGetWDInfo( &theWDPB, 0) != noErr )    
 return;
 
 fullPath[0] = ‘\0’; 
 theCPB.dirInfo.ioFDirIndex = -1; 
 theCPB.dirInfo.ioVRefNum = theHPB.volumeParam.ioVRefNum;      
 
 ClimbTree( theWDPB.ioWDDirID, 
 (CInfoPBPtr)&theCPB, 
 (StringPtr)fullPath );
 
 /*** Climbing the tree yields the names of  ***/
 /*** all the folders which we still need to ***/
 /*** add the file’s name to. ***/
 Concat( (char *)fullPath, (char *)&fName );
 paramPtr->returnValue = PasToZero( paramPtr, fullPath );
}

Listing:  HyperUtils.H
/********************************/
/* HyperUtils.H  */
/* Header file for HyperUtils.c  */
/* routines...   */
/********************************/
#define NIL 0L
#define UPFRONT  -1L
void  CenterWindow( WindowPtr wptr );
void  Concat( char * str1, char * str2 );
void  CopyPStr( char * pStr1, char * pStr2 );
short GetFileNameToOpen(SFTypeList typs,short typcnt, char *theName, 
short *theWDID);

Listing:  HyperUtils.c
/****************************/
/* HyperUtils.c  */
/* A collection of useful */
/* routines...   */
/****************************/
#include<MacTypes.h>
#include<OSUtil.h>
#include<MemoryMgr.h>
#include<FileMgr.h>
#include<ResourceMgr.h>
#include<StdFilePkg.h>
#include  “HyperXCmd.h”
#include  “HyperUtils.h”

void  CenterWindow( wptr )
 WindowPtrwptr;
/***************************
* Center a window in the current
* screen port.  Note: Does not
* attempt to work with multi-screen
* systems.
* This code is inspired by a
* similar routine written by Steve
* Maller in MPW Pascal.  Thanks Steve.
***************************/
{
 short  hWindSize = wptr->portRect.right - wptr->portRect.left;
 short  vWindSize = wptr->portRect.bottom - wptr->portRect.top;
 short  hSize = wptr->portBits.bounds.right - wptr->portBits.bounds.left;
 short  vSize = wptr->portBits.bounds.bottom - wptr->portBits.bounds.top;
 
 MoveWindow( wptr, ( hSize - hWindSize ) / 2, 
 ( vSize - vWindSize + 20) / 2, false);
}

void Concat( str1, str2 )
 char *str1;
 char *str2;
/*****************************
* Append string 2 to the end of
* string 1.  Both strings are 
* pascal-format strings.
* str1 must be large enough to hold
* the new string and is assumed to 
* be of Type Str255 (a pascal string)
*****************************/
{
 short len1 = *str1;/***number of chars in string 1***/
 short len2 = *str2++;/*** number of chars in string 2***/
 char  *temp;    /*** string pointer ***/
 
 if( len1 +len2  > 255 )
 len2 = 255 - len1;
 *str1++ += len2 ; /***add sizes together to get new size***/
 temp = str1 + len1;/*** move to end of string 1***/
 while( len2 ){
 *temp++ = *str2++;/*** add char to temp and move along***/
 --len2;/*** until all characters are added***/
 }
}

void  CopyPStr( pStr1, pStr2 )
 char *pStr1;
 char *pStr2;
/****************************
* Copy the contents of pstr1 into
* pstr2.  The strings are assumed 
* to be of type STR255 (length byte
* precedes data 
****************************/
{short  i;
 char *tstr;
 
 tstr = pStr2; 
 for( i = 0; i <= *pStr1; i++ )
 *tstr++ = *pStr1++;
}

short GetFileNameToOpen( typs, typCnt,theName, theWDID )
 SFTypeList typs; short   typCnt;
 char   *theName; short   *theWDID;
/*****************************
* Invokes SFOpenFile to query the 
* user for the name of a file to open.  
* In:   List of types of files to
*filter for (up to 4)
* Out:  fileName if picked in theName
*working directory in theWDID
*nil otherwise
*the file’s volum ref num.
* ( Note that the space for the 
* string must be allocated by the
* caller).
*****************************/
{
 Point  where;
 char   prompt[1];
 SFReplyreply;
 GrafPort *oldPort;
 WindowPtrdlogID;
 prompt[0]  = ‘\0’;
 /*** Get and put up the standard file ***/
 /*** dialog.  You will only see the file***/
 /*** types that you filtered for.  If ***/
 /*** you filtered for no files, then  ***/
 /*** all files will display***/
 GetPort( &oldPort );
 dlogID = GetNewDialog( (short)getDlgID, (Ptr)NIL, (Ptr)UPFRONT );
 SetPort( dlogID );
 CenterWindow( dlogID );
 where.h = dlogID->portRect.left;
 where.v = dlogID->portRect.top;
 LocalToGlobal( &where );
 SFGetFile( where, prompt, (Ptr)NIL, typCnt, typs, (Ptr)NIL, &reply );
 DisposDialog( dlogID );
 SetPort( oldPort );
 /*** If the user selected a file, let’s ***/
 /*** get the information about it ***/
 if (reply.good){
 *theWDID = reply.vRefNum;
 PtoCstr( (char *)&reply.fName );
 strcpy( theName, &reply.fName  );
 }
 return( reply.good );
}