The Strangest Thing

Usage and Config Platform
1

(imported topic written by Steve91)

…seems to be happening.

I’m running a job wich amongst other things creates a folder on the root of C: called “ENT”

The syntax in the action script as follows:

if {not exists folder “C:\ENT”}

dos MD C:\ENT

endif

This keeps failing, the directory is not being created so the next line in the action script fails.

Some details below:

Completed download http://xx.xx.xx.xx:52311/Uploads/d26742c30df79bc89d5f7fca0a0e8725ab46f3d7/Eventlog.tmp

Completed continue if {(size of it = 34635 AND sha1 of it = “d26742c30df79bc89d5f7fca0a0e8725ab46f3d7”) of file “Eventlog.tmp” of folder “__Download”}

Completed extract Eventlog.tmp

Completed delete __appendfile

Completed delete EventLogArchive.vbs

Completed delete dumpel.exe

Completed delete EventLogArchive.bat

Completed delete EventLogArchivebat.bat

Completed delete copyeventlog.bat

Completed if {not exists folder “C:\ENT”}

Completed dos MD C:\ENT

Completed endif

Failed if {not exists file “EventLogArchive.vbs” of folder “C:\ENT”}

dos copy “__Download\EventLogArchive.vbs” C:\ENT\

endif

if {not exists file “dumpel.exe” of folder “C:\ENT”}

dos copy “__Download\dumpel.exe” C:\ENT\

endif

…I’ve never had issues making directories in the past this way so I’m a bit stumped.

I’ve tried appending the MD command to a batch file and running that and it also fails.

Any ideas?

Cheers

Steve

2

(imported comment written by SystemAdmin)

What error are you getting in the client log?

You verified that the directory is not there?

3

(imported comment written by Steve91)

No error in the client log:

At 17:38:07 +0000 - opsite316 (http://xx.xx.xx.xx:52311/cgi-bin/bfgather.exe/opsite316)

Fixed - EventLog Script Update (Non Firewalled Servers) (fixlet:227360)

At 17:38:08 +0000 -

Report posted successfully.

And the directory is definitely not there before or after

4

(imported comment written by SystemAdmin)

The steps from your action script should appear in the clients log file when you executed the Action against it.

I am trying to see if it is failing on the IF line due to relevance substitution, which it may be doing if the directory does not exist.

If I take your actionscript to create the directory and run it in my test environment:

if {not exists folder “C:\ENT”}

dos MD C:\ENT

endif

It works fine.

Console

Completed if {not exists folder “C:\ENT”}

Completed dos MD C:\ENT

Completed endif

Client log

At 12:48:57 -0500 - actionsite (http://xxx.xxx.xxx.xxx:52311/cgi-bin/bfgather.exe/actionsite)

Command succeeded dos MD C:\ENT (fixlet 1513)

At 12:49:36 -0500 -

I have a mixed 7.x Main server, 6.x clients in my test environment.

Sometimes the client log can provide additional information that the console won’t necessarily show.

5

(imported comment written by Steve91)

I don’t get any entries relating to the stages of the action, although I do for other actions.

For instance i created an action that just creates the folder and as expected it reports in the log:

Command succeeded dos MD C:\ENT (fixlet 227625)

but for my main action I just get:

Fixed - EventLog Script Update (Non Firewalled Servers) (fixlet:227360)

…or:

Relevant - EventLog Script Update (Non Firewalled Servers) (fixlet:227627)

At 17:50:05 +0000 -

ActionLogMessage: (action 227627 ) action signature verified

ActionLogMessage: (action 227627 ) ending action

At 17:50:05 +0000 - actionsite (http://xx.xx.xx.xx:52311/cgi-bin/bfgather.exe/actionsite)

Not Relevant - EventLog Script Update (Non Firewalled Servers) (fixlet:227627)

Relevant - Status of Action 227627 (fixlet:2147711275)

At 17:50:06 +0000 -

Report posted successfully.

At 17:50:19 +0000 - actionsite (http://xx.xx.xx.xx:52311/cgi-bin/bfgather.exe/actionsite)

Not Relevant - Status of Action 227627 (fixlet:2147711275)

…I’ll re-create the task and see what happens

6

(imported comment written by SystemAdmin)

I think I ran into this before.

From what I have seen the client evaluates all of the IF … ENDIF statements before it runs any of the action script.

In this case it is erroring out on your relevancy statement before it starts.

Trying replacing your last relevancy checks with with the following:

not exists folder “C:\ENT” whose (exists file “EventLogArchive.vbs” of it)

not exists folder “C:\ENT” whose (exists file “dumpel.exe” of it)

This will return TRUE or FALSE instead of an error if the directory does not exist.

q:not exists file “dumpel.exe” of folder “C:\ENT”

E: Singular expression refers to nonexistent object.

q:not exists folder “C:\ENT” whose (exists file “dumpel.exe” of it)

A: True

T: 0.246 ms

I: singular boolean

q:not exists file “EventLogArchive.vbs” of folder “C:\ENT”

E: Singular expression refers to nonexistent object.

q:not exists folder “C:\ENT” whose (exists file “EventLogArchive.vbs” of it)

A: True

T: 0.261 ms

I: singular boolean

Let me know if it works out.

7

(imported comment written by Steve91)

Will do.

There’s actually 8 if/endif statements in the actions script so I’ll change each accordingly

8

(imported comment written by Steve91)

That did the trick!

Thanks for the help Iodom

I understood that parameters were evaluated before the action script ran but I didn’t know that IF statements were (and I guess the whole action script) I’ll remember that for future reference.

Just suprised I haven’t ran into it before.

Cheers

Steve

9

(imported comment written by SystemAdmin)

Yes,

It is a slipery one. Took me a while to figure it out when I ran into it the first time.

Glad I could Help.

Lewis

10

(imported comment written by jessewk)

Here’s a tip for this situation. You can guard your relevance statements like this:

if {not active of action OR …}

‘not active of action’ will evaluate to TRUE when the action isn’t running so the rest of the relevance will get skipped.

The reason all if statements are evaluated before the action is run is to support conditional downloads. If there is a download/prefetch statement in the if clause, the client needs to evaluate the statement to determine if it needs to get the download before actually running the action.

In our next release, we’ve changed the action language to specifically move all download/prefetch statements into a ‘prefetch block’ at the top of the action. This makes the behavior much more explicit and should allievate the problem you discovered.