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.