Vol Search XFCN
Volume Number: 7
Issue Number: 6
Column Tag: HyperChat
Related Info: File Manager
HFS Volume Search XFCN 
By Mark Armstrong, Pharos Technologies
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
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