Help with Search File System Wiz action

[napalmer]

I'm using the Search File System action to try and find an executable inside of Windows\system32\ but it won't find it (although I have verified the file is there on my testing maching). The SFS is setup like this:

Search name: ipxroute.exe
Search directories: $D(os_main)/system32/

Instead of looking for ipxroute, I tried cmd.exe just to make sure I could look in the directory and it was found so I'm not sure if there is some hidden aspect to some executables in sys32 that blocks us from finding them. Can anyone give me a hint on how to find this file besides using SFS... I'm really new to installers (InstallShield as well) so anything would be great.

[RobertDickau]

It doesn't seem as if it should matter, but perhaps use $D(lib) as the starting point? And if that executable won't be in a subdirectory, perhaps you can use the File Exists condition...

[napalmer]

I swapped over to using $D(lib) [the file won't be in a subdirectory, thats gauranteed] and tried both my SFS and the File Exists condition [$D(lib)/iscsiexe.exe ... ipx was my test value] but it still doesn't see the file.

[RobertDickau]

That's strange; as a test (of whether there's something special about System32), does it succeed if you set it up to detect a file in another directory?

[napalmer]

Yeah, I did a search for cmd.exe and it worked fine, brought up the absolutePath. tested a few other exes and some would show and some wouldnt.

[RobertDickau]

Hmmmm... Any obvious pattern to the files it doesn't find (subdirectory, file type, file attributes, ...)?

[napalmer]

I couldn't find any pattern, some of the files it can't find are dlls, some exes, some .sys. No consistent pattern in the attributes either and I am only trying files located on the sys32 directory

[RobertDickau]

Hmmm... Could you post the names of a couple files for which the search succeeds, and the names of a couple that fail? Perhaps someone can duplicate...

P.S. How are you determining whether the search/detection succeeds?

[napalmer]

There are more that succeed than fail but here some:

Sucess (all exe):
dllhost
secedit
finger
ipsec6
ipxroute

Fail (all exe):
iscsiexe
spupdsvc

I didn't go through all the exe's just a few. And to determine whether the search is successful I am using the SFS to search for each file (individually) and setting my product's Install Location to $W(Find#.absolutePath) where # is just some int I used to help discover which fails.

To test multiple ones at the same time I have something like this for my install location:
$W(Find1.absolutePath) + $W(Find2.absolutePath) + $W(Find3.absolutePath) + $W(Find4.absolutePath)

[RobertDickau]

In a quick test, displaying $W(findspupdsvc.absolutePath) [searching for spupdsvc.exe in $D(lib)] in a dialog box seemed to work, so it's not a problem specific to that file, I suppose. As a sanity check, are you using the same capitalization (Find1 vs. find1, $W vs. $w, etc.) throughout?

[napalmer]

If i am trying to find the file before the welcome dialog, would that matter? Yes i am using the same capitalization and spelling (using copy-paste cause I know better than to trust my typing)

[RobertDickau]

I think that shouldn't matter, but of course you can try moving the searches to see if it makes a difference... How are you setting the product install location to the search results? If you see half the values you're presumably doing things correctly, but at this point...

[napalmer]

To set the product installer I have Installation Design->(1st element = My Product)-> Install Location : $W(Find.absolutePath)

I'll try moving the search to a different section in a bit.

[napalmer]

Even moving the SFS to directly before the Destination Dialog still returns null for iscsiexe.exe

i've attached a screenshot of the SFS

[napalmer]

I just made a dummy project (completely empty except for two SFS one for iscsiexe.exe and another for iscsidsc.dll) and ran it on my development machine (Windows Server 2003 32-bit) and it successfully found both files. I then copied the installers over to my test machine (Windows Server 2003 64-bit) and tried them and they returned a null value.

Why would it return the values on one OS and not the other?

My test machine is using Microsoft iSCSI Initiatior 64-bit version while the dev is using iSCSI 32-bit. Would this affect the SFS?

[RobertDickau]

I don't have access to a 64-bit system immediately, but I might try (for example) displaying the fully qualified paths to the files (at least the values of $D(lib) and $D(os_main), anyway) in a dialog box to see if the values are being redirected...

[napalmer]

I just ran a check on the 64-bit machine for the values of $D(lib) and $D(os_main) and it returned C:\Windows\system32 and C:\Windows respectively.

How would I check the fully quailified paths beyond those two checks?