Things like servlets tend to have reduced permissions in ways that can be surprising. For example, you probably can't access a network shared directory. Such might be causing your script to fail. You might want to make sure STDERR of your script gets redirected to an appropriate place that you can check when debugging a failure but that periodically gets cleaned up (and that you are certain can always be written to). Perhaps like:

system("\"$fooDir/bar.bat\" 2>>D:/foo$$.log");
[download]

Does $fooDir contain spaces? Why are you adding the extra quotes around the command name?

You really should be checking the return value of system: system(...) == 0 or die "system failed, \$?=$?"; (see the docs for more detailed error checking).

Also, I'm sure you know you really should be using strict.

You probably should look into some modules such as IPC::Run3 or IPC::System::Simple for easier and "safer" execution of external commands.

Lastly, you can look into modules such as File::Spec, File::Path and friends for better handling of filenames and file operations.

Forgot one: Are you sure that $fooDir is always an absolute pathname?

Any ideas?

You didn't follow the rabbit trail of system documentation

You're calling the shell, and which shell depends on your perl configuration (its a variable)

$ perl -V:sh
sh='cmd /x /c';
[download]

Your goal should be to avoid the shell most of the time

This is a good point - unless you know that you need it, you should always avoid headaches and avoid the shell! Modules such as IPC::Run3 and IPC::System::Simple have an API that allows you to avoid calling the shell, make sure to read their docs. Anyway, here's the relevant bits of doc from system and exec:

Note that argument processing varies depending on the number of arguments. If there is more than one argument in LIST, or if LIST is an array with more than one value, starts the program given by the first element of the list with arguments given by the rest of the list. If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is /bin/sh -c on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to execvp, which is more efficient.

Using an indirect object with exec or system is also more secure. This usage (which also works fine with system()) forces interpretation of the arguments as a multivalued list, even if the list had just one argument. That way you're safe from the shell expanding wildcards or splitting up words with whitespace in them.

@args = ( "echo surprise" );
exec @args; # subject to shell escapes if @args == 1
exec { $args[0] } @args; # safe even with one-arg list
[download]

The first version, the one without the indirect object, ran the echo program, passing it "surprise" an argument. The second version didn't; it tried to run a program named "echo surprise", didn't find it, and set $? to a non-zero value indicating failure.