_FileListToArray AND FileFindFirstFile, etc. do not necessarily find all files

[Katharsis]

Does anyone know why this is the case? I have been trying to write a script to find whether or not a certain file exists in system32, and it ALWAYS detects that it doesn't, even when it does. Also, _FileListToArray() simply does NOT find all files in system32. Here is a screenshot as proof. I am running as Administrator on Windows 7.

The left side of the screenshot is an _ArrayDisplay of the results of _FileListToArray("C:\Windows\System32\"). The right side is the actual contents of a part of system32. The circles files are an example of what AutoIt does not pick up. I have Googled for this problem and found no results as of yet. This is a problem.

Edited December 9, 2011 by Katharsis

[Melba23]

Katharsis,

Those files are listed for me when I use _FileListToArray - Vista x32 SP2.

Can you have a special "hidden" type attributes set on those files in Win7?

M23

[Katharsis]

None of the files are marked as hidden. It's not just these files, either. It's a LOT of files. This is just a small snippet. Also, I can get this to work fine in VBscript to find the particular file that AutoIt doesn't show:

strDir = "C:\Windows\System32\"
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set objDir = oFSO.GetFolder(strDir)
wscript.echo getInfo(objDir)

Function getInfo(pCurrentDir)
For Each aItem In pCurrentDir.Files
  If LCase(aItem.Name) = "TestFile.txt" Then
   getInfo = aItem.Name
  End If
Next
End Function

If it won't work in AutoIt, is there a way I can pass the result of the VBscript back into AutoIt? (The AutoIt script is the main file, and it's already about 1000 lines.)

Edited December 9, 2011 by Katharsis

[Spiff59]

I can "Select All" in Windows Explorer while viewing C:\Windows\System32\ and get "2731 objects selected" showing on the status bar. A _FileListToArray() of the same folder also returns 2731 hits.

So, just to add input from the Windows XP SP3 crowd, it's working fine here, as it always has.

[Katharsis]

OK, well, I guess I'll have to figure out how to use VBscript to do it. But clearly _FileListToArray and FileFindFirstFile are not fully functional in Windows 7 x64 at least.

Also, for more specifics, in the above screenshot, localspl.dll and LocationApi.dll have the exact same permissions and attributes. AutoIt shows one but not the other.

EDIT:

OK, so I changed #AutoIt3Wrapper_UseX64=n to #AutoIt3Wrapper_UseX64=y. Now it is showing all the files in system32. However, this won't do, because this code needs to be run on our XP 32-bit machines and any 64-bit machines as well.

Edited December 9, 2011 by Katharsis

[Spiff59]

I wonder if some of the hocus pocus of folder redirection is causing you grief?

http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

Are the missing files actually in the sysWOW64 folder?

Edit: http://www.autoitscript.com/trac/autoit/ticket/1901

Edited December 9, 2011 by Spiff59

[Katharsis]

I wonder if some of the hocus pocus of folder redirection is causing you grief?

http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

Are the missing files actually in the sysWOW64 folder?

Hmm, no they really are in system32, but apparently it's the SysWOW64 folder that's being looked at when I have #AutoIt3Wrapper_UseX64 set to no. Does anyone know of a way to FORCE AutoIt to REALLY check system32 if I have #AutoIt3Wrapper_UseX64 set to no? I'm not sure why it thinks I want to look in SysWOW64 if I'm not telling it to. Is this a case of it thinking I'm an idiot? Also, why is it that VBscript doesn't do that, but AutoIt does? That's pretty frustrating.

Something else interesting: When I do MsgBox(0, "", @SystemDir), it will of course spit out C:WindowsSysWOW64. But apparently even if I use the aforementioned functions to look specifically at C:WindowsSystem32, it's as if AutoIt is vetoing me and saying, "No no no, idiot, you mean SysWOW64!" This is dumb. I say it's AutoIt because clearly VBscript doesn't do it.

E.g.

When I do this:

$arrFileList = _FileListToArray("C:\Windows\System32\")

AutoIt acts as if I'm doing this:

$arrFileList = _FileListToArray("C:WindowsSysWOW64")

Edited December 9, 2011 by Katharsis

[Spiff59]

Some related topics...

[Katharsis]

As for the first link, writing a variable workaround won't do anything, since I'm already spelling it out for AutoIt, and it still decides to veto me.

And the second link basically says it's not going to be fixed any time soon. In other words, AutoIt ousts me out of one of my own folders like a tyrant, and the developer says it's not being fixed, so the solution is to have two binaries. It's pretty upsetting for the developers to do this and think I don't know the difference between the two folders. I think it's time for me to move completely to VBscript.

Thank you for your input.

Edited December 9, 2011 by Katharsis

[BrewManNH]

Did you actually read the entire 1st thread? Because there's information in there that tells you how to disable file system redirection on an x64 version of Windows.

DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1) ;;Disables file system redirection for 32bit apps in 64bit land

[Katharsis]

Did you actually read the entire 1st thread? Because there's information in there that tells you how to disable file system redirection on an x64 version of Windows.

Yes, and the response after that, from an MVP, said this:

I would strongly suggest NOT to disable filesystem redirection! This can can and will lead to chaos and confusion on OS-Level and for other programs.

I took that to mean I shouldn't do it. I know they also said that it's only for the calling thread, but still, do you think this is safe?

Edited December 9, 2011 by Katharsis

[BrewManNH]

And he followed up with another response when it was mentioned that it only affects the calling thread (program) and doesn't affect other programs and once that thread ends, so does its redirection.

Me bad ...

Wow64DisableWow64FsRedirection: "Disables file system redirection for the calling thread. File system redirection is enabled by default."

[Katharsis]

Yes, I saw that (as I said I read it), but that didn't necessarily negate what he said before about it being dangerous. Even the link he provides from MS says: "Note This value is for system use only. To avoid unpredictable behavior, do not modify this value in any way." Anyway...

From that MS link I did find the Wow64RevertWow64FsRedirection call. I can do this to make sure it's safe and it will only run for just that portion of the script:

If @OSArch = "X64" Then DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)
$arrFileList = _FileListToArray("C:\Windows\System32\")
_ArrayDisplay($arrFileList)

If @OSArch = "X64" Then DllCall("kernel32.dll", "int", "Wow64RevertWow64FsRedirection", "int", 0)
$arrFileList = _FileListToArray("C:\Windows\System32\")
_ArrayDisplay($arrFileList)

The first portion of this will actually talk to System32. The second will talk to SysWOW64.

Problem solved. Thanks for the links.

Edited December 9, 2011 by Katharsis

[Malkey]

None of the files are marked as hidden. It's not just these files, either. It's a LOT of files. This is just a small snippet. Also, I can get this to work fine in VBscript to find the particular file that AutoIt doesn't show:

strDir = "c:\windows\system32\"
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set objDir = oFSO.GetFolder(strDir)
wscript.echo getInfo(objDir)

Function getInfo(pCurrentDir)
For Each aItem In pCurrentDir.Files
  If LCase(aItem.Name) = "TestFile.txt" Then
   getInfo = aItem.Name
  End If
Next
End Function

If it won't work in AutoIt, is there a way I can pass the result of the VBscript back into AutoIt? (The AutoIt script is the main file, and it's already about 1000 lines.)

Here is the AutoIt equivalent FYI.

Local $strDir = "c:\windows\system32\"
Local $oFSO = ObjCreate("Scripting.FileSystemObject")
Local $objDir = $oFSO.GetFolder($strDir)
ConsoleWrite( getInfo($objDir) & @LF)


Func getInfo($pCurrentDir)
    Local $sRet = ""
    For $aItem In $pCurrentDir.Files
        ;If StringLower($aItem.Name) == "TestFile.txt" Then ; Doesn't make sense.
            $sRet &= $aItem.Name & @LF
        ;EndIf
    Next
    Return StringTrimRight($sRet, 1)
EndFunc   ;==>getInfo