[futurebasic] [FB] Recursive Scan Files & Folders for OS X

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2006 : Group Archive : Group : All Groups

From: Steve Crossman <mactech@...>
Date: Thu, 19 Jan 2006 12:47:29 -0500
So I am working with the ScanFolder FSRec recursive scan example
My question is why I am getting the same vref for different folders?   
catInfoArray.volume

While I will be using the FSSpec, I am curious what this means.


TIA

~ steve

On Jan 9, 2006, at 6:13 AM, Alain Pastor wrote:

> Steve Crossman a écrit :
>> Ken,
>>>>>> Examples -> Files/Volumes -> FSRef ScanFolder -> ScanFolder  
>>>>>> FSRef recursive
>> How would I get the correct volume ref for a file, in any folder  
>> and what should I store [ FSpec ] from this recursive scan into a  
>> global array [ after removing clear local mode] so  that I can  
>> open any file, by name and vref or just the FSpec?
>> Basically, I am scanning a folder, looking for certain file types,  
>> and I access them again in a report, by opening the file.
>> I had been using the filename, and knowing the folder name,  
>> obtaining the vref #
>> But that falls apart in the USR ScanFolder
>> TIA
>> ~ desperate steve
>
> Steve,
>
> What you could do is to store the array of FSSpecs returned by the  
> FSGetCatalogInfoBulk function into a global handle. Actually, you  
> can have two different strategies :
>
> a) you can deal with the file types after the scan.
> b) you can store only the appropriate FSSpecs within the scan loop.
>
> Option a is simpler because you just have to copy the array of  
> FSSpecs to the handle without checking anything else but a possible  
> memory failure.
>
> Suppose you have a global handle:
>
> Begin Globals
> Dim As Handle gSpecsHndl
> End Globals
>
> You could write:
>
> err = Fn PtrToHand( FSSpecArray,gSpecsHndl,actualCount*Sizeof 
> (FSSpec) )
> If err != _noErr Then Def DisposeH(gSpecsHndl)
>
> On each iteration of the recursive search a new array of FSSpecs is  
> concatenated to the handle.
> If a memory error occurs, you trash the handle and since err is set  
> the scan will be properly aborted (meaning here that the various  
> allocated pointers will be disposed of).
> This assumes that the global handle has been initialized prior to  
> the scan with:
>
> gSpecsHndl = Fn NewHandle(0)
>
> Then later in your program you can Xref your handle and deal with  
> each item:
>
> Long If gSpecsHndl
>   Dim As Long i, specCount
>   Xref@ mySpecs(_maxInt) As FSSpec
>
>   mySpecs = gSpecsHndl
>   specCount = Fn GetHandleSize(gSpecsHndl) \\ Sizeof(FSSpec)
>   Long If specCount
>     For i = 0 to specCount - 1
>       Long If Fn FSpGetFileType( mySpecs(i) ) == "XXXX"
>         // do something with the file
>       End If
>     Next
>   End If
> End If
>
>
> FSpGetFileType could probably read like this:
>
> Clear Local Mode
> Local Fn FSpGetFileType( f As .FSSpec )
>   Dim As OSErr  err
>   Dim As FInfo  info
>
>   err = Fn FSpGetFInfo( #f, info )
>
> End Fn = info.fdType
>
> Don't forget to get rid of your global handle once you're done with  
> it:
>
> If gSpecsHndl Then Def DisposeH( gSpecsHndl )
>
> Method b consists in checking the file type within the scan loop.  
> You would have probably something like this in your scan routine:
>
> For index = 0 To actualCount - 1
>   Long If (catInfoArray.nodeFlags( index ) And  
> _kFSNodeIsDirectoryMask) == _kFSNodeIsDirectoryMask
>     err = Fn IterateFolder( FSRefArray(index) )
>   Xelse
>     Long If catInfoArray.Finderinfo.fdType(index) == "XXXX"
>       err = Fn PtrToHand(@FSSpecArray(index),gSpecsHndl,Sizeof 
> (FSSpec))
>       If err != _noErr Then Exit For
>     End If
>   End If
> Next
> If err != _errFSNoMoreItems Then Def DisposeH( gSpecsHndl )
>
> That method would probably give a slower scan due to the numerous  
> calls to PtrToHand, but in any case FSGetCatalogInfoBulk is very  
> fast and I believe way much faster than Usr ScanFolder.
>
> Now there is still a caveat in OS X, because you cannot trust the  
> Finder file type, some files may not have one. Perhaps there are  
> reliable Toolbox routines to deal also with extensions, but at the  
> moment I'm not aware of any. It's time to visit Apple's  
> documentation, I guess...
>
> Alain
> PS: The code above has not been tested, use with caution.
>
> --
>


Attachments: