Recursively search files in a folder
LOCAL FN TotalBackup (FromFolder$,ToFolder$,FRefNum%,TRefNum%,level) FOR x = 1 TO 3000 RefNum% = FRefNum% FromFile$ = FILES$(-x, "",FromFolder$, RefNum%) LONG IF LEN (FromFile$) LONG IF INSTR(1,FromFile$,":") 'is a folder newFromFolder$ = FromFolder$ + FromFile$ newFRefNum% = FOLDER(newFromFolder$,0) newToFolder$ = ToFolder$ + FromFile$ newTRefNum% = FOLDER(newToFolder$,0) LONG IF newTRefNum% = 0 RefNum% = TRefNum% newTRefNum% = FOLDER(newToFolder$,RefNum%) END IF FN TotalBackup (newFromFolder$,newToFolder$,newFRefNum%,newTRefNum%,level+1) XELSE ToFile$ = FromFile$ FN BackupFile (FromFile$,ToFile$,FRefNum%,TRefNum%) END IF XELSE x = 3000 END IF NEXT END FNThis backs up files. FN Backupfile is not included...
FN Total Backup calls itself each time it finds a new folder. You can patch this up to give you a list of files.
(1) Some time ago I found the following FBII-code that does the recursive search _without_ stack problems. It is based on the code proposed by Apple (IM-1992/Files/2-43) and works under OS 6.x but is rather slow.
A recursive cat search for mini-runtime applications and/or code resources. by R.W. Lambert & Mel Patrick, Copyright copyright 1995, Ariel Publishing, Inc.
(2) An elegant and much faster solution (OS 7.x and newer) is to use PBCatSearch (IM-1992/Files/2-204). There is an Apple's example code as well (IM-1992/Files/2-38) and in the FB examples folder you will find this demo:
by Ross W. Lambert, Copyright copyright 1995, Ariel Publishing, Inc. All Right Reserved
A search cache of 16k for PBCatSearch at least doubles the search speed.
In general, you can pass either a full or partial path name in the 3rd parameter of FILES$(-x,...), as long as the path name specifies a directory (rather than a file). A full path name always contains at least one colon but never begins with one. A partial (relative) path name either begins with a colon, or contains no colons. If you use a partial path name, the path is considered to be relative to the current default directory. The simplest partial path name is just ":", which indicates, "the current default directory." Examples:
FILES$(-n, , ":", v%) returns an item in the current default directory;
FILES$(-n, , "myDisk:", v%) returns an item at the root level of the volume called "myDisk" (note the colon);
FILES$(-n, , "xyz", v%) looks for a folder called "xyz" within the current default directory, and returns an item that's in "xyz" (note no colon);
FILES$(-x,,path$,vRefNum%) returns the name of a file or folder which is located in the directory specified by path$. If the returned name ends with a colon, it's a folder; otherwise it's a file. If "x" is greater than the number of files & folders within the specified directory, then FILES$ returns an empty string.
FILES$ only returns the names of items within the _first level_ of the indicated directory--not within any deeper directories.
FILES$(-x, , path$, vRefNum%) returns a true volume reference number (_not_ a working directory reference number, strangely enough) corresponding to the volume which contains the returned item. This number is _not_ suitable for passing to the OPEN statement, unless the file you want to open happens to be in the volume's root directory. Your best bet may be to try to build a full path name ending with the file's name, and passing that to OPEN (when you pass a full path name to OPEN, the vRefNum% parameter is ignored).