Filegrep on output file via redirection from command console

[texmags]

(IS 2009, Basic MSI, InstallScript)

Hi, I have a Custom Action that is run in the Execute sequence after the sequence "Duplicate Files" which calls my InstallScript function. I want my function to run a console app to add a file to SharePoint and redirect the output to a text file so I can figure out if the command worked.

My problem is that if my output file doesn't already exist on the file system, FileGrep returns -2 (FILE_NOT_FOUND). I have tried to add a long timeout instead of the argument LAAW_OPTION_WAIT for nTimeOut argument of the LauchApplication function(100000 ms) but it still doesn't seem to make a difference. I can reproduce the problem with a regular command app like "dir".

It works fine if I run the setup package a second time and use "Repair" option for example or just uninstall the setup but leave the output.txt file on the file system.

Am I doing something wrong or is there some other way people are doing it like writing it to an install log file via MSI command arguments (in basic MSI project, Release/Production Configuration 1/Release 1/Setup tab setting the MSI Command line arguments to something like "/L*ve %TEMP%\Install.log") ?

My function is below:

export prototype InstallPackage(HWND);

function InstallPackage(hMSI)
STRING sCommand;
NUMBER nLength, nvResult;

begin

if (LaunchApplication ("CMD.EXE"
, " /C dir > C:\\output.txt"
, "C:\\"
, SW_HIDE
, LAAW_OPTION_WAIT
, LAAW_OPTION_WAIT)) = ISERR_SUCCESS then

nvResult = FileGrep ("C:\\output.txt", "Volume in drive", sCommand,
nLength, RESTART);
NumToStr(sCommand, nvResult);
MessageBoxEx(sCommand, "nvResult", INFORMATION);
endif;

end;

TIA,
Magnus

[MGarrett]

texmags,
I'm not sure if this will solve your problem, but have you tried writing the output file to a location other than the root of C:? I've seen some strange errors (especially on Vista) when trying to do any sort of file operations on the root folder of the boot drive, even with full permissions.
Unfortunately, I can't think of any specific examples to reinforce my point, but I've had enough problems that I have learned to avoid writing any files on the root of the drive. Instead, try writing to the TEMP folder and see what happens.

[texmags]

I tried to do everything in the TEMP folder instead but I experience the same issue. It's good to know for future reference though. I'm not planning to install it in the root of course but I thought it would be easier first to get it to install from there.

I noticed the filegrep is definitely a timing issue, if I use Delay(2); after it has launched the application before I try to read the file, then the file is there. Without Delay(), I get the same issue if I try to open the file with OpenFile instead of FileGrep.

I think using the Delay() function for this purpose is a hack though, I assume I'm not using the correct option in LaunchApplication so it waits until the console command has been executed completely before moving on. Or perhaps I'm not fully understanding the execution cycle of Deferred Execution.

-Magnus

[MGarrett]

texmags,
Hmmm, I'm as surprised as you by this behavior. I would expect the LAAW_OPTION_WAIT to fix this issue, at least in your example code using cmd.exe. I wouldn't expect cmd.exe to return until the file write is complete.

Have you tried using LAAW_OPTION_WAIT_INCL_CHILD ? Maybe the process that writes the output file is spawning another background process, causing LaunchApplication to return prematurely.

Have you tried this on another computer? It could be that this PC has some crazy disk caching that is doing a delayed-write.

The Delay() does seem to be a bit of a hack, but if it works consistently, go for it. If the LAAW_OPTION_WAIT_INCL_CHILD doesn't solve the problem, you could try checking if the file is locked before continuing with FileGrep.

if( IS(FILE_LOCKED, "C:\\output.txt") ) then
Delay(2);
endif;

[texmags]

I just tried LAAW_OPTION_WAIT_INCL_CHILD but at least on my computer it doesn't seem to make a difference. I will try it on another computer to be sure but of course another computer than the one I have access to might have some crazy caching settings like you suggest. I think for my particular case, it might have been better to create a managed custom action but since I'm new to Install Shield, I thought it would be easier to use a command line tool.

Thanks for the suggestion of using Is(FILE_LOCKED), I will make sure I use that for now.

-Magnus