"Scripting.FileSystemObject" problem

[malik641]

Hey guys,

I'm was trying to write some code for a friend of mine and I was using the "Scripting.FileSystemObject", but I'm finding (by debugging) that when I set an Object variable to the FileSystemObject object, it returns nothing:dunno why is that?

Could this not be supported by his system? It doesn't seem right to me. And I'm not familiar enough with this Scripting object to understand why it's not creating an instance of it.

If it matters:

Windows XP Professional edition
Excel 2003

Thanks everyone :)

[Jacob Hilderbrand]

Do you have the reference set? Or are you using late binding? Can you post the relevant code?

[Bob Phillips]

Some places will not allow scripting as they believe it is a security loophole. Your friend's site might be one.

[malik641]

It uses late binding. Here's a sample that won't work:


Option Explicit
Dim FSO As Object

Sub ProcessFiles()
Dim I As Long
Dim sFolder As String
Dim fldr As Object
Dim Folder As Object
Dim file As Object
Dim Files As Object
Dim this As Workbook
Dim cnt As Long
Set FSO = CreateObject("Scripting.FileSystemObject")
Set this = ActiveWorkbook
sFolder = "C:\Testing"
If sFolder <> "" Then
Set Folder = FSO.GetFolder(sFolder)
Set Files = Folder.Files
cnt = 1
For Each file In Files
Select Case Right(file.Name, 3)
Case "wav": MsgBox file.Name
Case "txt": MsgBox file.Name
Case "pdf": MsgBox file.Name
End Select
Next file
End If
End Sub

Bob, how can I find out if my friend's computer might be blocking the use of the Scripting object?

Thanks

[Bob Phillips]

Joseph,

Get him to ask his IT support people, they should know,

Another way is to look and see if there is a scripting DLL on his machine, it is called scrrun.dll, get him to search for it in explorer.

[malik641]

Thanks Bob, I'll be using the latter...as there is no IT help where he's at (or at least I haven't seen one....).

[Bob Phillips]

Keep us posted, I am interested to know how many sites are stopping this.

BTW, if there is no IT, who implemented the desktop?

[malik641]

Ok, I'll keep you posted.

And I'll bet it was contracted out. Or maybe the boss just did it himself because there's no server where they are right now....but he's moving his office and contracted a friend of mine to configure their new network. Which actually ends up with more projects for me :) (this is that extra part-time that I have from my other thread).

I'm going to ask if there's an IT department, but I really think there isn't.

[Bob Phillips]

I'm going to ask if there's an IT department, but I really think there isn't.

If there isn't, and the DLL doesn't reside on that machine, installing it should be no big deal.

[malik641]

Could I just copy my scrrun.DLL and bring it to his computer and place it in the system registry? Or are there other items I need?

[Bob Phillips]

I would think you could just copy it, and then register it (put an icon of regsrv32.exe on the desktop and drag the dll onto that, or Regsvr32 C:\YourPath\scrrun.DLL at a command line prompt). I don't think there are licensing issues with scrrun, but put it in windows\system32.

[malik641]

Huh, I didn't know that could be done like that.

Anyway he told me that the file was found in:

C:\WINDOWS\ServicePackFiles\i386
C:\WINDOWS\SYSTEM32
C:\i386

So I'm not sure what the problem could be. Maybe a corrupt DLL file :dunno


I have a side question. What actually happens when you use CreateObject("Class as String",[server name])? What I mean is how does it know where to find the DLL file to create an instance of the object you're calling?

[Bob Phillips]

I guess in would look in all paths defined in the Path system variable.

[Bob Phillips]

Oh, and the application path of course.

[mvidas]

You're saying he has scrrun.dll in system32 and it isn't working? He would get the msgbox in this case?:

Sub PAFSO4EVR()
Dim FSO As Object
Set FSO = CreateObject("scripting.filesystemobject")
If FSO Is Nothing Then MsgBox "wtf"
End Sub

Odd. What about if he did try early binding, or at least just adding the reference to it. That might be able to tell if the dll is corrupt or anything.

If you're doing this via vba, you could always just not use fso.. :)

[malik641]

:giggle I like the messagebox.


If you're doing this via vba, you could always just not use fso.. :)
I did go another route for what I needed to do...but Bob was saying that there are imperfections to using (example) Application.FileSearch......but I haven't ran into it yet, not to mention I don't know what those imperfections are (what are they, anyway, Bob?). And I don't like knowing that I could write code that has faults (even if they are made by someone else).


You know what confuses me. Why does the CreateObject return nothing without an error being raised?



I guess in would look in all paths defined in the Path system variable.
Oh, and the application path of course.
What is the Path system variable?

Looking at some of the References I noticed that they're not all in the same folder...so are there (correct me if I'm wrong) pointers in the registry to find where the DLL files are?

...I have no idea. I'll do some digging.

[mvidas]

:giggle I like the messagebox.What about using early binding.. any problem?


I did go another route for what I needed to do...but Bob was saying that there are imperfections to using (example) Application.FileSearch......but I haven't ran into it yet, not to mention I don't know what those imperfections are (what are they, anyway, Bob?). And I don't like knowing that I could write code that has faults (even if they are made by someone else).Why even use that? I understand it is easy (which is why people use FSO), but you can use the dir() method to get what you need, the only limitation to that (IMO) is that you can't use it in vbscript.


You know what confuses me. Why does the CreateObject return nothing without an error being raised?very good question. It does if you use something like


Dim X As Object
Set X = CreateObject("create.object")

Run-time error '419':
ActiveX component can't create object



What is the Path system variable?
msgbox environ("path")


Looking at some of the References I noticed that they're not all in the same folder...so are there (correct me if I'm wrong) pointers in the registry to find where the DLL files are?go to start/run, open up regedit, and do a find for "scripting.filesystemobject". That will take you to a ProgID folder for the fso guid, go to the InprocServer32 folder for that guid and look at the default value.. what is it returning?

[malik641]

I'm going to have to get back to you about Early binding and the RegEdit things because I'm not with my friends laptop right now. I'll see if he can bring it to his home this weekend and try these things out.


About Dir()....I'm more familiar with Application.FileSearch, but I'll be taking a look at that.

And thanks for the Path explanation :thumb

I have another question about that. For my computer at work it returned:

C:\Program Files\Microsoft Office\OFFICE11\
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
C:\Program Files\Common Files\Autodesk Shared\

So what exactly is this returning?

[mvidas]

About Dir()....I'm more familiar with Application.FileSearch, but I'll be taking a look at that.For your consideration:

Option Explicit
Sub ExampleSub()
Dim FileList() As String, i As Long
ReDim FileList(1, 0)
vFileSearch "C:\foldername\", FileList
If Len(FileList(0, 0)) > 0 Then 'make sure at least one file
Debug.Print "Total files found: " & CStr(UBound(FileList, 2) + 1)
For i = 0 To UBound(FileList, 2)
Debug.Print FileList(0, i) & FileList(1, i)
Next
End If
End Sub

Function vFileSearch(ByVal vPath As String, ByRef vsArray() As String, _
Optional ByVal vExt As String = "*", Optional ByVal SubDirs As Boolean = True) As Boolean
Dim tempStr As String, vDirs() As String, Cnt As Long, dirCnt As Long
If Len(vsArray(0, 0)) = 0 Then
Cnt = 0
Else
Cnt = UBound(vsArray, 2) + 1
End If
If Right(vPath, 1) <> "\" Then vPath = vPath & "\"
If SubDirs Then
On Error Resume Next 'in case no 'read' rights to directory
tempStr = Dir(vPath & "*.", vbDirectory)
On Error GoTo 0
dirCnt = 0
Do Until Len(tempStr) = 0
If Left(tempStr, 1) <> "." Then
ReDim Preserve vDirs(dirCnt)
vDirs(dirCnt) = tempStr
dirCnt = dirCnt + 1
End If
tempStr = Dir
Loop
End If
On Error Resume Next 'in case no 'read' rights to directory
tempStr = Dir(vPath & "*." & vExt)
On Error GoTo 0
Do Until Len(tempStr) = 0
ReDim Preserve vsArray(1, Cnt)
vsArray(0, Cnt) = vPath
vsArray(1, Cnt) = tempStr
Cnt = Cnt + 1
tempStr = Dir
Loop
If SubDirs Then
If dirCnt > 0 Then
For dirCnt = 0 To UBound(vDirs)
If Len(Dir(vPath & vDirs(dirCnt))) = 0 Then
vFileSearch vPath & vDirs(dirCnt), vsArray, vExt, SubDirs
End If
Next
End If
End If
End Function




And thanks for the Path explanation :thumb And what an explanation it was!




I have another question about that. For my computer at work it returned:

C:\Program Files\Microsoft Office\OFFICE11\
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
C:\Program Files\Common Files\Autodesk Shared\

So what exactly is this returning?It is used for a variety of things, but one you can actually see is that any program or executable in those folders can be called without qualifying the path name. So it you have "runme.exe" in c:\windows\system32\wbem, going to start/run and typing "runme" will execute that program. The path is often set in the autoexec.bat file processed when the pc starts
Matt

[Bob Phillips]

...but Bob was saying that there are imperfections to using (example) Application.FileSearch......but I haven't ran into it yet, not to mention I don't know what those imperfections are (what are they, anyway, Bob?).

How imperfect do you want?

Sometimes, it returns a smaller number of files than it should. Sometimes, that smaller number is 0.

[Bob Phillips]

How imperfect do you want?

Sometimes, it returns a smaller number of files than it should. Sometimes, that smaller number is 0.

BTW, MS have acknowledged the failings of FileSearch, and dropped it from Excel 2007.

[malik641]

Thanks for the code sample Matt.


It is used for a variety of things, but one you can actually see is that any program or executable in those folders can be called without qualifying the path name. So it you have "runme.exe" in c:\windows\system32\wbem, going to start/run and typing "runme" will execute that program. The path is often set in the autoexec.bat file processed when the pc starts
Matt
Is there any good documented information you know about so that I can read about it?



How imperfect do you want?As imperfect as it gets!


BTW, MS have acknowledged the failings of FileSearch, and dropped it from Excel 2007.Do you know if they will be replacing it with a new function?

And Bob, does the same imperfection you mentioned happen with Dir()?

[mvidas]

Is there any good documented information you know about so that I can read about it?Strangely I really couldn't find anything more than what I put above, just worded differently. One such example:
The system path is a list of folders, separated by a semicolon, that identifies the folders that the system should search when looking for files that are called from the Run dialog box, command line, or other processes.



does the same imperfection you mentioned happen with Dir()?The Dir method in vb should not have the same thing as above, unless the file just doesn't exist. The Dir method is the same as if you went to a command line and typed "dir", except it returns a single file rather than the list of files. I'd be curious to hear if it did have any imperfections like the filesearch method

[SamT]

This from "Inside MS-DOS 6"

PATH tells DOS where to look for a program or batch file in the event that file can't be found in the current directory."

Another way of looking at it;

A path is the drive designator ( C: ) and all the folder names down to the file, concantenated together with a '\' (Backslash.)

On my computor the path to excel.exe is

"C:\Program Files\Microsoft Office\Office"

Its' Dir is slightly different

"C:\Program Files\Microsoft Office\Office\"

And the fully qualified name of the excel program is

"C:\Program Files\Microsoft Office\Office\excel.exe"

Actual use of any of these will require double quotes because of some spaces in the string and because some of the folder names are longer than 8 characters

[Zack Barresse]

BTW, MS have acknowledged the failings of FileSearch, and dropped it from Excel 2007.

I was sad to see when they did this. I thought they should have worked on it and made it more reliable/robust, but they took the easy way out and just dropped it.

@Joseph: They didn't replace it with anything (AFAIK), which would mean you're either going to use the Dir() or FSO method.

[Bob Phillips]

I was sad to see when they did this. I thought they should have worked on it and made it more reliable/robust, but they took the easy way out and just dropped it.

@Joseph: They didn't replace it with anything (AFAIK), which would mean you're either going to use the Dir() or FSO method.

Why? Who needs 3 ways of doing it? If it's broke, and there are alternatives, ditch it. Makes sense to me.

[malik641]

Why? Who needs 3 ways of doing it? If it's broke, and there are alternatives, ditch it. Makes sense to me. When FileSearch did work, it seemed to be a lot faster than FSO (not sure about Dir() though)


And thanks SamT for the explanation :thumb

[Zack Barresse]

Why you ask? Because I like having a native method designed and built especially for the task at hand. The Dir() function was not intentionally designed (at least I don't think so) for looping through folders and subfolders, plus it's not always the best choice as it can fail under certain conditions. The FSO method is great and I love it, but it's dependent on creating objects from a dynamic link library, which I don't mind but is not always the best solution (IMO).

I admit, I tend to use FSO more than anything else because I find it easier and more comfortable. I was more comfortable knowing there was a native method for exactly what I wanted to do. Drop it? No, by all means do not drop it just because it has some shortcomings. By that very same logic there would be no more methods to which this could be done.

[mvidas]

When FileSearch did work, it seemed to be a lot faster than FSO (not sure about Dir() though)

The setup:Option Explicit
Private FSO As Object
Sub SpeedTestCheckCDrive()
Dim AnArrayDir() As String, AnArrayFSO() As String, i
Dim Timer1 As Double, Timer2 As Double
ReDim AnArrayFSO(0)
ReDim AnArrayDir(0)
Timer1 = Timer
Set FSO = CreateObject("scripting.filesystemobject")
ReturnAllFilesUsingFSO "C:\", AnArrayFSO
Set FSO = Nothing
Timer1 = Timer - Timer1
Timer2 = Timer
ReturnAllFilesUsingDir "C:\", AnArrayDir
Timer2 = Timer - Timer2
Debug.Print "FSO took " & Timer1 & " seconds, " & UBound(AnArrayFSO) + 1 & " files found"
Debug.Print "DIR took " & Timer2 & " seconds, " & UBound(AnArrayDir) + 1 & " files found"
End Sub
Function ReturnAllFilesUsingDir(ByVal vPath As String, ByRef vsArray() As String) As Boolean
Dim tempStr As String, vDirs() As String, Cnt As Long, dirCnt As Long
If Len(vsArray(0)) = 0 Then
Cnt = 0
Else
Cnt = UBound(vsArray) + 1
End If
If Right(vPath, 1) <> "\" Then vPath = vPath & "\"
On Error GoTo BadDir
tempStr = Dir(vPath, 31)
Do Until Len(tempStr) = 0
If Asc(tempStr) <> 46 Then
If GetAttr(vPath & tempStr) And vbDirectory Then
ReDim Preserve vDirs(dirCnt)
vDirs(dirCnt) = tempStr
dirCnt = dirCnt + 1
End If
BadDirGo:
End If
tempStr = Dir
SkipDir:
Loop
On Error GoTo BadFile
tempStr = Dir(vPath, 15)
Do Until Len(tempStr) = 0
ReDim Preserve vsArray(Cnt)
vsArray(Cnt) = vPath & tempStr
Cnt = Cnt + 1
tempStr = Dir
Loop
BadFileGo:
On Error GoTo 0
If dirCnt > 0 Then
For dirCnt = 0 To UBound(vDirs)
If Len(Dir(vPath & vDirs(dirCnt))) = 0 Then
ReturnAllFilesUsingDir vPath & vDirs(dirCnt), vsArray
End If
Next
End If
Exit Function
BadDir:
If tempStr = "pagefile.sys" Or tempStr = "???" Then
' Debug.Print "DIR: Skipping: " & vPath & tempStr
Resume BadDirGo
ElseIf Err.Number = 52 Then
' Debug.Print "No read rights: " & vPath & tempStr
Resume SkipDir
End If
Debug.Print "Error with DIR: " & Err.Number & " - " & Err.Description
Exit Function
BadFile:
If Err.Number = 52 Then
' Debug.Print "No read rights: " & vPath & tempStr
Else
Debug.Print "Error with DIR: " & Err.Number & " - " & Err.Description
End If
Resume BadFileGo
End Function
Function ReturnAllFilesUsingFSO(ByVal vPath As String, ByRef vsArray() As String) As Boolean
Dim f As Object, fld As Object, Cnt As Long
Set fld = FSO.GetFolder(vPath)
If Len(vsArray(0)) = 0 Then
Cnt = 0
Else
Cnt = UBound(vsArray) + 1
End If
On Error GoTo UhOhs
For Each f In fld.Files
ReDim Preserve vsArray(Cnt)
vsArray(Cnt) = f.path
Cnt = Cnt + 1
Next
For Each f In fld.SubFolders
ReturnAllFilesUsingFSO f.path, vsArray
Next
LaterGater:
Set f = Nothing
Set fld = Nothing
Exit Function
UhOhs:
If Err.Number = 70 Then
' Debug.Print "Permission denied: " & vPath
Else
Debug.Print "Error with FSO: " & Err.Number & " - " & Err.Description
End If
Resume LaterGater
End Function



FSO took 46.1400000000026 seconds, 36102 files found
DIR took 7.6870000000032 seconds, 36102 files found

Matt

[malik641]

Error with DIR: 5 - Invalid procedure call or argument
FSO took 70.9949999999965 seconds, 62771 files found
DIR took 1.60000000011635E-02 seconds, 1 files found
Not sure why I got the error...(error from my work computer)

I'm going to have to look at this later (so I can fully understand what's going on), but well done :thumb

Could you add the Application.FileSearch method as part of your procedure to compare?


And by the way, about the original problem, it has to wait until this weekend because I don't have time to get with my friend (test on Friday...been studying since monday :mkay )

[mvidas]

Hmmmm... odd!

I only got the error 5 when it was checking a directory I didnt have access to (like C:\docs&settings\Administrator).

At the end of "return all files using dir", add "or err.number=5" to the 52 lines, like:' ElseIf Err.Number = 52 Then
ElseIf Err.Number = 52 Or Err.Number = 5 Then
'and
' If Err.Number = 52 Then
If Err.Number = 52 Or Err.Number = 5 ThenSee if that gets rid of it.

Another thing you could try (in place of the above if you're not getting anywhere) could be to change the two lines ofDebug.Print "Error with DIR: " & Err.Number & " - " & Err.Descriptionand identify the errorchecking part it is in, likeDebug.Print "Error with DIR (BadDir): " & Err.Number & " - " & Err.Description
'and
Debug.Print "Error with DIR (BadFile): " & Err.Number & " - " & Err.Description
The fact that you didnt get any results (despite it saying 1, just because of the +1 after ubound) makes me wonder if perhaps this line somehow got messed up in the copy/paste: ReturnAllFilesUsingDir "C:\", AnArrayDirMatt

[mvidas]

Could you add the Application.FileSearch method as part of your procedure to compare?
Woops, missed this part. Sure let me add it (though I've never used it, it shouldnt be tough to figure out, thats the point of it, right?)
I think I'll add the API filesearches as well

[mvidas]

Updated code (no API yet):
Option Explicit
Private FSO As Object
Sub SpeedTestCheckCDrive()
Dim AnArrayDir() As String, AnArrayFSO() As String, i As Long, FSCnt As Long
Dim Timer1 As Double, Timer2 As Double, Timer3 As Double, Timer4 As Double
ReDim AnArrayFSO(0)
ReDim AnArrayDir(0)

Timer1 = Timer
Set FSO = CreateObject("scripting.filesystemobject")
ReturnAllFilesUsingFSO "C:\", AnArrayFSO
Set FSO = Nothing
Timer1 = Timer - Timer1
DoEvents
Timer2 = Timer
ReturnAllFilesUsingDir "C:\", AnArrayDir
Timer2 = Timer - Timer2
DoEvents
Timer3 = Timer
FSCnt = ReturnFileCountUsingFileSearch("C:\")
Timer3 = Timer - Timer3

Debug.Print "FSO took " & Timer1 & " seconds, " & UBound(AnArrayFSO) + 1 _
& " files found"
Debug.Print "DIR took " & Timer2 & " seconds, " & UBound(AnArrayDir) + 1 _
& " files found"
Debug.Print "FileSearch took " & Timer3 & " seconds, " & FSCnt & " files found"
End Sub
Function ReturnAllFilesUsingDir(ByVal vPath As String, ByRef vsArray() As String) _
As Boolean
Dim tempStr As String, vDirs() As String, Cnt As Long, dirCnt As Long
If Len(vsArray(0)) = 0 Then
Cnt = 0
Else
Cnt = UBound(vsArray) + 1
End If
If Right(vPath, 1) <> "\" Then vPath = vPath & "\"
On Error GoTo BadDir
tempStr = Dir(vPath, 31)
Do Until Len(tempStr) = 0
If Asc(tempStr) <> 46 Then
If GetAttr(vPath & tempStr) And vbDirectory Then
ReDim Preserve vDirs(dirCnt)
vDirs(dirCnt) = tempStr
dirCnt = dirCnt + 1
End If
BadDirGo:
End If
tempStr = Dir
SkipDir:
Loop
On Error GoTo BadFile
tempStr = Dir(vPath, 15)
Do Until Len(tempStr) = 0
ReDim Preserve vsArray(Cnt)
vsArray(Cnt) = vPath & tempStr
Cnt = Cnt + 1
tempStr = Dir
Loop
BadFileGo:
On Error GoTo 0
If dirCnt > 0 Then
For dirCnt = 0 To UBound(vDirs)
If Len(Dir(vPath & vDirs(dirCnt))) = 0 Then
ReturnAllFilesUsingDir vPath & vDirs(dirCnt), vsArray
End If
Next
End If
Exit Function
BadDir:
If tempStr = "pagefile.sys" Or tempStr = "???" Then
' Debug.Print "DIR: Skipping: " & vPath & tempStr
Resume BadDirGo
ElseIf Err.Number = 52 Then 'or err.number=5 then
' Debug.Print "No read rights: " & vPath & tempStr
Resume SkipDir
End If
Debug.Print "Error with DIR (BadDir): " & Err.Number & " - " & Err.Description
Debug.Print " vPath: " & vPath
Debug.Print " tempStr: " & tempStr
Exit Function
BadFile:
If Err.Number = 52 Then 'or err.number=5 then
' Debug.Print "No read rights: " & vPath & tempStr
Else
Debug.Print "Error with DIR (BadFile): " & Err.Number & " - " & Err.Description
Debug.Print " vPath: " & vPath
Debug.Print " tempStr: " & tempStr
End If
Resume BadFileGo
End Function
Function ReturnAllFilesUsingFSO(ByVal vPath As String, ByRef vsArray() As String) _
As Boolean
Dim f As Object, fld As Object, Cnt As Long
Set fld = FSO.GetFolder(vPath)
If Len(vsArray(0)) = 0 Then
Cnt = 0
Else
Cnt = UBound(vsArray) + 1
End If
On Error GoTo UhOhs
For Each f In fld.Files
ReDim Preserve vsArray(Cnt)
vsArray(Cnt) = f.path
Cnt = Cnt + 1
Next
For Each f In fld.SubFolders
ReturnAllFilesUsingFSO f.path, vsArray
Next
LaterGater:
Set f = Nothing
Set fld = Nothing
Exit Function
UhOhs:
If Err.Number = 70 Then
' Debug.Print "Permission denied: " & vPath
Else
Debug.Print "Error with FSO: " & Err.Number & " - " & Err.Description
End If
Resume LaterGater
End Function
Function ReturnFileCountUsingFileSearch(ByVal vPath As String) As Long
'just using this count for a speed test, since most people wouldnt want
' the results in an array
With Application.FileSearch
.NewSearch
.SearchSubFolders = True
.LookIn = vPath
.FileType = msoFileTypeAllFiles
' .FileName = "*.*"
If .Execute > 0 Then
ReturnFileCountUsingFileSearch = .FoundFiles.Count
End If
End With
End Function


FSO took 29.6239999999985 seconds, 36070 files found
DIR took 10.6090000000024 seconds, 36070 files found
FileSearch took 47.7339999999984 seconds, 35661 files found

FSO took 32.3739999999976 seconds, 36070 files found
DIR took 7.9839999999982 seconds, 36070 files found
FileSearch took 34.9050000000015 seconds, 35661 files found
Didnt bother sending the results to a text file or anything to see what files weren't included. Can anyone who uses filesearch regularly tell me if my function could be improved/sped up?

[mvidas]

Interesting.. it appears that getting the filenames from FSO is what takes the longest. I changed the code on all (and added the API method) to only return file counts from the search. Rather than paste it, I'm just going to attach the exported module, but here were the results (again, simply a count):
FSO took 4.92199999999808 seconds, 36314 files found
DIR took 7.23399999999942 seconds, 36314 files found
FileSearch took 55.4210000000027 seconds, 35905 files found
APIs took 11.9990000000006 seconds, 36313 found

[mvidas]

Weird.. application.filesearch returned a result to me, at least a count. Now when I'm looping through the results to add to an array, I got a 'permission denied' error on it, even when I just hover over .foundfiles(i)
Interesting, filesearch can see it, but my access privileges prevent me from seeing it. Apparently it only happened 4 times on my C:\, but still odd nonetheless that the filesearch method has more access than the currentuser.

Uhhh, now that I got past that I'm getting an "Out of Memory" error?! When I highlight the .FoundFiles(i) again I'm seeing Out of Memory. Should I be using anything like ".FoundFiles(i).FileName" or .Name or anything?
Cant be a huge deal as the .foundfiles.count at the start was 36020, and only 36007 items in the resulting array ... could this be another 'imperfection' of using filesearch?

OK, last part of my thread clutter. Changed each to return a resulting array:

FSO took 49.8429999999996 seconds, 36429 files found
DIR took 13.7960000000015 seconds, 36429 files found
FileSearch took 55.8890000000002 seconds, 36007 files found
APIs took 26.9530000000031 seconds, 36428 files found
'** CLEARED INET CACHE **'
FSO took 29.6090000000002 seconds, 36012 files found
DIR took 7.50000000000023 seconds, 36012 files found
FileSearch took 41.2490000000002 seconds, 35590 files found
APIs took 19.9059999999968 seconds, 36011 files found

My findings:
-dir is fast
-fso is faster if you just need file counts
-filesearch is slow whether you need filename array or not (iterating through results doesnt add much runtime)
-these apis are fun
-internet cache takes a long time to look through
QED, for now

final module attached