Related Info: File Manager

HFS Volume Search XFCN

By Mark Armstrong, Pharos Technologies

The SearchVol XFCN

The SearchVol XFCN searches the specified volume and returns the full path name of the file. This is extremely useful if you want to launch a document from within Hypercard but you are not sure where the file is located on the volume. SearchVol will return the full pathname of the file which you can then pass directly to the Hypertalk open command.

SearchVol uses a recursive algorithm to walk through the hierarchical file structure looking for a match. If it finds a match, it constructs the full path name by walking back up the tree. Once it has the full path name, it returns it to Hypercard. If no match is found, the XFCN will return empty. See the Other Issues section of this article for further discussion of the recursive nature of the algorithm.

SearchVol searches in the specified volume, or, if no volume is specified, in the system volume. Since PBGetVInfo prefers to have the volume specified in the form “volname:” (and since I am in the unfortunate habit of just passing “volume” without the trailing colon,) we simply check to see if there is a trailing colon on the specified volume name. If there is not, we add one.

Once we have the volume reference numbers we can begin the search. We start by determining the number of files and directories in the root directory by calling PBGetCatInfo and then we make the initial call to SearchFile, which is the real guts of the XFCN.

The Search Engine

The SearchFile function is very similar to Clifford Story’s walktree function in the October ’88 MacTutor (Programmer’s Workshop; HFS Transfer DA) Cliff wrote his in Pascal - this one is in C. But the structure of the routines is quite similar. For the gospel on searching HFS volumes, refer to Apple’s Technical Note 68.

You will notice that SearchFile consists of two for loops. The first for loop is looking for files. We look for file by accepting only the cases in which bit 4 of ioFlAttrib is not set. The second for loop is looking strictly for directories. If it is a file, then we check to see if there is a match. If it is a directory, then we look inside that directory with a recursive call to search file.

So, why the two for loops? Well, I wanted the routine to be equivalently fast for any file in a given directory. With just a single for loop, a file in the route directory named “AAAA” would most likely be found very quickly. Where as, a file named “ZZZZ” would take much longer, assuming, of course, that the volume in question was an average user’s 40 meg hard disk. Consequently, if we look through all the files first for a given directory before diving down to the next level in the hierarchy, we should be able to get a more consistent search time for files at the same hierarchical level. Once the recursive searching is complete, we check to see if a file was found. If a file was not found, fErr will contain fnfErr. On the other hand, if a file was found then we need to walk back up the hierarchy to construct the full path name that Hypercard requires for its file commands such as open, read, and print. We build the path name in the returnValue handle so it is available when we return to Hypercard.

Error Handling

In the SearchVol XFCN listed below I have included only a skeletal version of the required error handling. I have done this so as not to cloud the concepts on which I am trying to focus. However, I do have a few words about error handling that I would like to share.

There is an interesting catch-22 situation that arises for the author of external functions. The situation is this. If Hypercard is expecting you to return a value from an external function, then Hypercard needs a way to determine if the returned value is an error string or the expected result. In many XFCN’s available today, it is difficult (if not impossible) to determine in the general case if the string returned from the external is an error or not. As an example, suppose there is an XFCN that returns a file name. Furthermore, lets say that in case of error, the XFCN returns the error number. Now lets say that the XFCn is called from Hypertalk and the returned result is “-43”. Is this an error code for file not found or is it just a file that happens to be named “-43”. To avoid these problematic circumstances, the XFCN designer must make it very easy for the Hypertalk programmer to ascertain:

1) If an error occurred

2) What was the nature of the error

Another common approach is to return empty if an error occurred. Unfortunately, empty does not tell the Hypertalk programmer (to say nothing of the user) what went wrong. Consequently, it is difficult to take appropriate action.

Some programmers have circumnavigated the problem by forcing the declaration of a global variable. If an error occurs, then the global variable is set to notify Hypertalk that things did not go as planned. This method works has its advantages, but it can be an extra hassle if the Hypertalk programmer does not know he is required to declare the global. Whatever you decide to do, make your error checking rigorous and complete. Everyone will benefit.

Other Issues

SearchVol, as it is, is a foundation on which one can build. For example, one could easily search all mounted volumes by creating an outside loop that walked through the volume queue. For example:

/* 1 */

QHdrPtr QQ;
VCB     *Cur;

QQ = GetVCBQHdr();
Cur = (VCB *)(QQ->qHead);
   
do {
   /* Use Cur->vcbVN as the current volName */
   /* Put search volume code here */
   Cur = (VCB *)(Cur)->qLink;
   } while (Cur != 0L);

Another possibility is to extend the XFCN so that it returns all occurrences of the specified file - rather than just the first occurrence. In such a case, you would not return after finding a file but would simply store the full pathname of the file and then continue the search down the hierarchy. In this way, you could duplicate in Hypercard the functionality of the Find File desk accessory.

Other ideas include filtering out files by type or modification date, cataloging subdirectories on a volume, and the list goes on.

Finally, it is important to discuss the advantages and limitations of using a recursive algorithm for hierarchical searching. The advantages are that the code is small and simple. The primary limitation is that the stack grows with each recursive call. On a large hard disk or CD-ROM this could be a problem. I have used the recursive algorithm as a demonstration of recursive methods in an ideal world. Reality dictates that machines have a finite amount of memory. It is more prudent to employ methods which are not recursive if there is any possibility of exceeding available stack space.

/*------------------------------------------------
 SearchVol XFCN
 © 1989 MacTutor
 by Mark Armstrong    Pharos Technologies, Inc
 written in Think’s LightspeedC 3.0
------------------------------------------------*/

#include “HyperXCmd.h”
#include “FileMgr.h”
#include “HFS.h”
#include “ResourceMgr.h”
#include “SetUpA4.h”

#define False    0
#define True!False
#define Nil 0L

/*--------------------------------------
XFCN main function
--------------------------------------*/
pascal main(paramPtr)
   XCmdBlockPtr  paramPtr;
   {
   Str255 fName,str,fullPath,vName;
   HParamBlockRecMyHPB;
   CInfoPBRec    MyCIPB;
   OSErrfErr;
   shorttheVol;
   Handle nameH;
   long theDir,foundDir;
   
   RememberA0();
   SetUpA4();
   
   if ((paramPtr->paramCount < 1) || 
 (paramPtr->paramCount > 2)) 
   {
   SysBeep(10);
   /* return error string */
   goto Done;
   }
   
 ZeroToPas(paramPtr,*((unsigned char **)           paramPtr->params[0]), 
fName);
   if (paramPtr->paramCount == 2)
   {
   ZeroToPas(paramPtr,*((unsigned char **)               paramPtr->params[1]),vName);
   if (vName[vName[0]] != ‘:’)
   {
   vName[0]++;
   vName[vName[0]] = ‘:’;
   }
 MyHPB.volumeParam.ioCompletion = Nil;
 MyHPB.volumeParam.ioNamePtr = vName;
 MyHPB.volumeParam.ioVRefNum = 0;
 MyHPB.volumeParam.ioVolIndex = -1;
 fErr = PBHGetVInfo(&MyHPB,False);
 if (fErr)
 {
        SysBeep(10);
        /* return error string */
        goto Done;
 }
 theVol = MyHPB.volumeParam.ioVRefNum;
 }
   else theVol = GetSysVol();
   
   MyCIPB.dirInfo.ioCompletion = 0L;
   MyCIPB.dirInfo.ioNamePtr = 0L;
   MyCIPB.dirInfo.ioVRefNum = theVol;
   MyCIPB.dirInfo.ioFDirIndex = 0;
   MyCIPB.dirInfo.ioDrDirID = 2L;
   fErr = PBGetCatInfo(&MyCIPB,False);
   
   if (fErr)
 {
   SysBeep(10);
   /* return error string */
   goto Done;
 }
 else
   {
   fErr = 
 SearchFile(2L,
 MyCIPB.dirInfo.ioDrNmFls,
 theVol,
 &fName,
 &foundDir);
   if (fErr)
 {
   SysBeep(10);
   /* return error string */
   goto Done;
 }
 
   fullPath[0] = 0;
   PstrCopy(fullPath,fName);
   
   MyCIPB.dirInfo.ioCompletion = Nil;
   MyCIPB.dirInfo.ioNamePtr = str;
   MyCIPB.dirInfo.ioVRefNum = theVol;
   MyCIPB.dirInfo.ioFDirIndex = -1;
   MyCIPB.dirInfo.ioDrDirID = foundDir;
   fErr = PBGetCatInfo(&MyCIPB,False);
   PrependStr(MyCIPB.dirInfo.ioNamePtr,fullPath);
   
   do {
   MyCIPB.dirInfo.ioDrDirID =
 MyCIPB.dirInfo.ioDrParID;
   fErr = PBGetCatInfo(&MyCIPB,False);
   if (fErr == noErr)
 PrependStr(MyCIPB.dirInfo.ioNamePtr,fullPath);
   } while (fErr == noErr);
   
   paramPtr->returnValue =  PasToZero(paramPtr,(StringPtr)fullPath);
   }

Done:
   RestoreA4();
   }
  
/*--------------------------------------------
SearchFile is the recursive hierarchical search engine.  It looks at 
all the files and then all the folders in the directory specified by 
theVol and theDir for the file specified by fName
--------------------------------------------*/
SearchFile(theDir,count,theVol,fName,foundDir)
 long   theDir;
   shortcount,theVol;
   Str255 *fName;
   long *foundDir;
   {
   shortI;
   OSErrfErr;
   Str255 str;
   CInfoPBPtr    MyCIPB;
   
   MyCIPB = (CInfoPBPtr)NewPtr(sizeof(CInfoPBRec));
   for (I=1;I<=count;I++)
   {
   str[0] = 0;
   MyCIPB->dirInfo.ioCompletion = Nil;
   MyCIPB->dirInfo.ioNamePtr = str;
   MyCIPB->dirInfo.ioVRefNum = theVol;
   MyCIPB->dirInfo.ioFDirIndex = I;
   MyCIPB->dirInfo.ioDrDirID = theDir;
   fErr = PBGetCatInfo(MyCIPB,False);
   if (fErr) 
   {
   SysBeep(10);
   return (fErr);
   }
   else
   {
   if (!(MyCIPB->dirInfo.ioFlAttrib &  0x10))
   {
   if (EqualString(fName,
 MyCIPB->dirInfo.ioNamePtr,
 False,True))
   {
   *foundDir = 
 MyCIPB->hFileInfo.ioFlParID;
   return (0);
   }
   }
   }
   }
   
   for (I=1;I<=count;I++)
   {
   str[0] = 0;
   MyCIPB->dirInfo.ioCompletion = Nil;
   MyCIPB->dirInfo.ioNamePtr = str;
   MyCIPB->dirInfo.ioVRefNum = theVol;
   MyCIPB->dirInfo.ioFDirIndex = I;
   MyCIPB->dirInfo.ioDrDirID = theDir;
   fErr = PBGetCatInfo(MyCIPB,False);
   if (fErr) 
   {
   SysBeep(10);
   return (fErr);
   }
   else
   {
   if (MyCIPB->dirInfo.ioFlAttrib & 0x10)
   {
   fErr = 
 SearchFile(
 MyCIPB->dirInfo.ioDrDirID,
   MyCIPB->dirInfo.ioDrNmFls,
   theVol,
   fName,
   foundDir);
   if (!fErr) return (0);
   }
   }
   }
   
   DisposPtr(MyCIPB);
   return (fnfErr);
   }

/*--------------------------------------------
PrependStr puts string s1 and a colon before string s2.
--------------------------------------------*/
PrependStr(s1,s2)
 char   *s1,*s2;
 {
 Str255 temp;
 PstrCopy(temp,s2);
 s1[0]++;
 s1[s1[0]] = ‘:’;
 PstrCopy(s2,s1);
 BlockMove(&(temp[1]),&(s2[s2[0]+1]),
 (long)temp[0]);
 s2[0] += temp[0];
 }

/*--------------------------------------------
PstrCopy copies string s2 into string s1
--------------------------------------------*/
PstrCopy(s1,s2)
 char   *s1,*s2;
 {
 short  len;
 for (len=*s2;len>=0;--len) *s1++ = *s2++;
 }

/*--------------------------------------------
GetSysVol returns the vRefNum of the startup system volume.
--------------------------------------------*/
GetSysVol()
   {
   shortvRefNum;
   OSErrFErr;
   FErr = GetVRefNum(SysMap,&vRefNum);
   return vRefNum;
   }

[Mark Armstrong is presently the Vice President of Technical Operations for Pharos Technologies, Inc., a system integration and software development firm. He is the author of UNITize™, and has contributed to several other projects such as Milo™ and Marble Madness™.]