FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

DISK I/O

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 FN
This 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.
Ian

Dear Seachers...

(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.

FN catSearch.BAS
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:

PBCatSearch 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.

Herbie

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).

Rick