possible issue: unrequested blocking of nested .bat files.

[Tim Weller]

Hello,

This may be a repeat post since the search functionality
was not working when I am adding this so I couldn't check
thouroghly. Anyhow:

I have been using the MS AS BETA1 and as part of my
activities I use two .bat files (call them A.bat and
B.bat). They are basically setup like this (pseduo-code):

A.bat:
call B.bat
xcopy *.* ...

B.bat:
xcopy *.* ...

When I go to execute A.bat, the MS AS BETA1 activtes and
requests permission to allow a script to run. I tell it to
let the script run and execution of A.bat begins as
expected. I see that B.bat is called first as expected and
it operates correctly (verified by inspecting the result of
the xcopy). Then I see that the call to xcopy in A.bat is
made and the following types of errors occur:

'xcopy' is not recognized as an internal or external
command, operable program or batch file.

the failure is verified by inspection of the destination
(none of the files that were to be copied by A.bat are
present). xcopy.exe is available in the system and the
Path environment variable is setup correctly (vereified by
calling xcopy from basic command prompt successfully and by
the successful B.bat file operation...)

I do not know exectly what is going on but the MS AS BETA1
system seems to be acting like it chose to block the
activities of any .bat file that is not at the (nesting)
layer that is a leaf and performs work first(?) It also did
not prompt for permission to run script after the first
time, but it seems to be treating the two .bat file
contents as seperate somehow... perhapes the "call" .bat
command consused it...

All I can say from my experiences is that when I closed
down the MS AS BETA1 the two .bat files worked as expected
and the issure reappeared as soon as I started MS AS BETA1
again.

perhapes there is a setting that I missed, but I could not
find anything that seemed to pertain to this situation...

Hope this is helpful to others and the MS AS BETA1 dev team.

Thanks,
- Tim.

 

[Bill Sanderson]

Thanks Tim. There is a known and being fixed bug with batch files:

On the first call, the one where you get prompted, the batch file is run in
the context of the system32 directory, rather than the usual default.

This occurs only on the first run--thereafter, without the prompt--the
command should run correctly.

It sounds as though what you are describing involves either more than this
bug would cover, or a different issue--I'll see if I can replicate it here.

Thanks for bringing this up. The product is being reworked, and this may
already be fixed, but I'll check it out and your post may help others with
similar batch files.