Another request for quick independent re-test please: GET_FILESYSTEM in 12.1

[Carsten Schmitz]

Hi,

before I go and file an incident, could some kind soul please do a quick independent test for me, preferably with 12.1, but I'll take 12.0 experiences as well:

Make a script with the following content:

:SET &FREESPACE# = GET_FILESYSTEM(SOME_WINDOWS_AGENT,"C:\",FILESYSTEM_SPACE_FREE,GB)
:print &FREESPACE#

Of course, pick a valid agent name and valid drive.

All my production 10.x agents return useful values for their hosts. All of the several 12.1.0+HF2 agents I tried return nothing but "U00020408 0000000000000000".

Thanks, much appreciated!

[Anon Anon]

here you go: 2018-01-30 13:52:30 - U00020408 Automation Engine Version: 11.2.6 2018-01-30 13:52:30 - U00020408 ------------------------------------- 2018-01-30 13:52:30 - U00020408 Agent Version: 11.2.6+build.816 2018-01-30 13:52:30 - U00020408 ------------------------------------- 2018-01-30 13:52:30 - U00020408 &FREESPACE# = 0000000000000000 2018-01-30 12:52:02 - U00020408 Automation Engine Version: 12.0.3 2018-01-30 12:52:02 - U00020408 ------------------------------------- 2018-01-30 12:52:02 - U00020408 Agent Version: 12.0.3+build.791 2018-01-30 12:52:02 - U00020408 ------------------------------------- 2018-01-30 12:52:02 - U00020408 &FREESPACE# = 0000000000000000 2018-01-30 13:52:18 - U00020408 Automation Engine Version: 12.1.0 2018-01-30 13:52:18 - U00020408 ------------------------------------- 2018-01-30 13:52:18 - U00020408 Agent Version: 12.1.0+build.796 2018-01-30 13:52:18 - U00020408 ------------------------------------- 2018-01-30 13:52:18 - U00020408 &FREESPACE# = 0000000000000000 cheers, Wolfgang

[Carsten Schmitz]

Many thanks.

But ... how can this ... I mean ... can it be that it's broken in 11.x as well and nobody ever ... do you see anything wrong with my script syntax, or are you as puzzled as I am?

[Anon Anon]

you re welcome :-)

[edit]
sorry for the bad format - I shouldn't have installed FF noscript ;-)

cheers, Wolfgang

[Carsten Schmitz]

(edit): nevermind, I think I see what you were saying before the edit. I'll put this into an incident, as it clearly seems broken.

[Carsten Schmitz]

INC00219303

[Anon Anon]

I did play around last week with 11.2.2 AE and a V9 Unix Agent in my Test systems with GET_Filesystem.

Result was a crashed Unix agent ....

honestly I did some "undocumented function research" - so I can not say if this caused it, or the combination V11.2 AE and V9 Agents...

cheers, Wolfgang

[Anon Anon]

of course I was a bit courious - so I played with several Agent versions (AE 11.2.6)

GET_FILESYSTEM(&AGENT#,"C:\",FILESYSTEM_SPACE_FREE,GB)

Agent Parameters:
Win64 SP6 - Result: 00
Win64 SP5 - Result: 00
Win64 SP3 - Result: 00
Linux64 SP5 - Result: 00

cheers, Wolfgang

[Carsten Schmitz]

Cheers! I have linked this thread in the Incident, so hopefully they'll look at your additional findings as well.

When I get the time I will experiment with UNIX as well. And the next step then is probably to check whether other GET_FILESYSTEM operations are broken, too.

What I'm really wondering though is: Why didn't anyone discover this thus far, seemingly, if it's happening with V11, too - is nobody using these functions? *puzzled*

[Anon Anon]

I am not that astonished about that - have a look at the documentation - there's a bunch of limitations - especially Unix is an orphan- operatingsystem...

so I can understand that hmmmm *not everyone* uses this script command in *every* Job ;-)

My personal (evergreen-) Solution for this is...

...Yes, PREP_PROCESS + OS command

:-)

cheers, Wolfgang

[Anon Anon]

My good deed for the day:

 

GET_FILESYSTEM - remove limitations on differen Operating Systems 

[Anon Anon]

Carsten Schmitz said:

 And the next step then is probably to check whether other GET_FILESYSTEM operations are broken, too.

.. I must say I am shocked - you are offline before 8 pm ???
So Inspector Brueckler deducts, you as IT guy have a life off the keyboard?
just a joke, don't be offended ;-)


so - doing your tasks - I tested the parameters (AE11.2.6, Agent WIN- 11.2.3, 11.2.4, 11.2.5, 11.2.6):

• FILESYSTEM_SPACE_FREE,GB
  
• FILESYSTEM_SPACE_TOTAL,GB
• FILESYSTEM_SPACE_USED,GB
  

result was always zero...

cheers,
Workaholic

[Carsten Schmitz]

Wolfgang Brueckler said:

.. I must say I am shocked - you are offline before 8 pm ???
So Inspector Brueckler deducts, you as IT guy have a life off the keyboard?
just a joke, don't be offended ;-)

No worries - as the self-professed partial Ex-Geek (but Geek-stuff-adjacent character still), I'd be kinda offended if you'd be implying that I had a life! But I must admit that since I'm old now, I leave work sometimes even when the sun is still up, to head to my newly found humble abode in the unbelievably small (but peaceful) town that OBI has dediced to have it's world headquarters in. Many years ago I'd then have been sat down to do some Linux hacking, but alas, these days I went straight from work PC to (a, properly) working PC (i.e. my own), for a sweet game of Internet Spaceships.

[Carsten Schmitz]

GET_FILESYSTEM functionality in various AE: Confirmed "broken" by Automic (INC00219303).

Has been transferred to development.

[nafetS]

 AE 12.1.1 - Win Agent 12.1.1

FILESYSTEM_SPACE_FREE,GB = 0 :(

[Carsten Schmitz]

Stefan Rieger said:

 AE 12.1.1 - Win Agent 12.1.1

FILESYSTEM_SPACE_FREE,GB = 0 :(

Thanks for another confirmation.

I may use this to share the problem number assigned to this by Automic now: PRB00219855.

Best,
Carsten

[Carsten Schmitz]

Exciting!

I have been told that Automic development has analyzed my PROBLEM report and concluded that it's a permission problem, because starting with version 11, one needs to specify the login object, or have ANONYMOUS_FE='Y' set.

Well, I didn't know about this, and the documentation for AE 11.2 and 12.1 certainly doesn't either, because both say that the login object remains optional, and don't mention ANONYMOUS_FE at all.

So is this just an oversight and a documentation bug? Erm ... no.

Well, good thing we have ANONYMOUS_FE='Y' anyway. Hooray!

So I tried GET_FILESYSTEM (free space mode) for C:\ with a login object anyway, and had it print the error number, error message and and variable part ( sys_last_err_ins() ) as suggested by Automic. The result is ... interresting.

Login object: yes
Path to check: C:\
Error #: 11700
Error: U00011700 Cannot find information for path 'C:\$Recycle.Bin\S-1-5-21-1899719792-992224312-1087139693-116516'

Login object: no
Path to check: C:\
Error #: 11700
Error: U00011700 Cannot find information for path 'C:\Documents and Settings'.

Login object: no
Path to check: C:\UC4
Error #: none
Error: none. It actually works!

So there you have it, plain and simple:

When asked to get the FREE space (!!!), the agent for some reason descends into directories, and it falls over flat over something like $Recycle.Bin, or it's content, or possibly "Documents and Settings".

C:\UC4 is full of plain, old, boring files with 8+3 letter names, and it works perfectly.

True. Quality. Software.

I'm awaiting curiously how this one will be fixed (and why it even descends into sub directories to get the free space ...).

Best,
Carsten

[Carsten Schmitz]

*sigh*

A "solution" by Automic, and one that, FYI, actually works if you don't have a gazillion existing scripts, is to add the "N" value for the subdirectory parameter:

GET_FILESYSTEM(MY_AGENT,"C:\",FILESYSTEM_SPACE_FREE,GB,N)

Use this as a workarround if it helps you.

Why this software descends into sub-directories by default when it's clearly not needed is beyond me ...

Nevertheless, we have hundreds of scripts already without the "N" parameter, and I want Automic to either fix this or at least acknowledge that something changed. So I installed a V10 and a V12 agent on the exact same machine and executed the exact same GET_FILESYSTEM() script (without the "N" parameter), with only a differing agent name. Everything else: script, file system etc. is identical.

The result is, V10 works, V12 fails.

[Carsten Schmitz]

Okay, I have received another update to PRB00219855. I will try to replicate it as genuine as possible for any other parties interested in this matter. This will probably also be the last update I make on this. Because eventhough I'm not sure if what I received from Automic is truly the final word on this, it's definetly the point at which I stop caring (and quite frankly, the current ticket after import into CA system is now such a garbled mess that I can't tell anymore what is a quote, what isn't, or what belongs where).

 

However, the gist to the best of my understanding is:

 

• GET_FILESYSTEM was "rebuilt" since version 10
• the ability to add the "N" to instruct it not to traverse sub directories when reporting free space was added
• my personal opinion: it appears that sub directory traversal was never needed to get a result for FREE_SPACE, and was possibly always bloat
• the fact that GET_FILESYSTEM currently fails is said to be because there are permission problems
• my personal opinion: I'm not sure on that, and I believe this isn't the whole story. Because it apparently fails e.g. over directories I believe the SYSTEM account has permissions to, but alas, I stopped caring
• the fact that GET_FILESYSTEM with the FREE_SPACE operation in version 10 worked without falling over any permission problems is said to be a bug, while the behaviour in v11, v12 where it fails is the expected behaviour
• my personal opinion: ... ooooookay (backs away slowly ...) - then why not make "N" for the parameter to traverse sub directories (or not) the default; since that was newly added post v10, you're not breaking any compatibility by making "N" the default, on the contrary, it would have prevented this whole mess
• alas, the solution for v11 and onwards is to add the "N" parameter to each and every legacy call to GET_FILESYSTEM in existing scripts, and always use it from here on, as if it were the default that frankly, it should have been.

 

The later is what I will have my users do.

 

Best regards,

Carsten