On Jan 15, 2009, at 11:54 AM, Robert Covington wrote: > > On Jan 15, 2009, at 1:41 PM, Brian Stevens wrote: > >> >> On Jan 15, 2009, at 6:20 AM, Steve wrote: >> >>> I am having an issue when scanning a folder that has more than >>> 32767 files in it. >> >> Had some discussion with Steve offlist and he is now using >> FSGetCatalogInfoBulk. Just a couple points about USR ScanFolder >> ( for which I'm updating the doc ) >> >> (1) USR ScanFolder relies on the deprecated in 10.4 >> PBGetCatInfoSync call and also the older FSSpec. The newer >> replacement ( PBGetCatalogInfoSync ) relies on FSRefs but obviously >> USR ScanFolder is currently coded to use FSSpecs. It's probably >> possible to write an FSRef version of USR ScanFolder that uses the >> more modern call but that exercise is left to the individual >> programmer. There are no plans to increase the number of USR/DEFs >> in FB5 and some will be eliminated for various reasons >> ( incompatibility, redundant etc. ). >> >> (2) Even though I haven't tested this, my suspicion is the two-byte >> integer parameter block field named ioFDirIndex might be related to >> the 32,767 limit encountered by Steve >> >> >> Brian S > > Can you re-iterate all that? Thanks for levity RC! One more comment since there are not only new FBers on the list but new programmers: Even with the comparatively fast FSGetCatalogInfoBulk call, scanning is a relatively slow method to find a file and open it. If the folder location and file name are known, going directly to that folder and file(s) is much faster ( both in code necessary and execution speed ) than scanning hundreds of folders and the hundreds/thousands of files within those folders. The new File Directory calls ( see FB5 examples folder ) are suited to this. Brian S.