[Xymon] Question on filesystem line processing for Windows in do_disk.c for UNC resources

[Deiss, Mark]

I am not sure about how BBWIN is reporting its Windows client metrics;
MrBig for Windows reports file system usage in the following format:


Filesystem    1k-blocks        Used       Avail    Capacity  Mounted
C              15727603     8740006     6987597       55.6%  /FIXED/C
D             277225672     6502600   270723072        2.3%  /FIXED/D


Limits:
Drive      Yellow     Red       
D          70.0       80.0      
C          70.0       80.0      
Default    90.0       95.0  

We have some clustered Windows 2008 servers that are using shared
resources that are only referenced by their UNC paths - they do not have
logical drive assignments. Was wondering whether this would cause any
issues with the processing in do_disk.c section:


/* 
		 * Some Unix filesystem reports contain the word
"Filesystem".
		 * So check if there's a slash in the NT filesystem
letter - if yes,
		 * then it's really a Unix system after all.
		 */
		if ( (dsystype == DT_NT) && (*(columns[5])) &&
(strchr(columns[0], '/')) )
			dsystype = DT_UNIX;


Where the columns[5] would be referring to the "Mounted" column in the
MrBig output, and columns[0] would be referring to the Filesystem
column.  The above logic is not being performed as a block step against
the overall client's disk output but rather on a line by line basis of
the disk output. The first occurrence matched will flip the subsequent
data processing flow from Windows based to Unix based even for
subsequent disk lines from the same client. 

My question is whether the presence of UNC only mounts would be
represented with backslashes (\) with the BBWIN/MrBig/whatever Windows
reporting modules or whether they may end up converted to forward
slashes (/) and thus falsely trigger the dsystype switch. The only
affect on the subsequent processing is whether the Filesystem column
(Windows OS) is used for storing the diskname (and generation of the rrd
file name) or the "Mounted on" column is used for the diskname (Unix
OS).
	If the UNC representation can cause this false flip, then
initial Windows disk lines that are using logical drive assignments
would be stored and referenced using the one column reference and once a
UNC line is encountered, then it and all subsequent lines (including
logical drive assignment lines) would be using the other column
reference convention.
	Things could get busy if the line order varies from time to time
(i.e. addition/removal of a UNC resource); then a logical drive time
stamped data line may go in at times as a "Filesystem" rrd file, other
times as a "Mounted on" rrd file. 

setupfn2("%s%s.rrd", testname, diskname);

As I don't yet have any clients installed in these clustered Windows
boxes or UNC only mounts on other boxes, I don't know what the "Mounted
on" column output would look like for the UNC resource. If
BBWIN/MrBig/whatever are not reporting on UNC resources then that's
going to be an (separate) issue for us too. 

Possible fix if this is an issue:

Was wondering if all the Windows clients (BBWIN/MrBig/whatever) all
reliable report the last column with the "Mounted" header tag and
whether all the Unix/Linux/BSD variants report their last column with
the "Mounted on" header tag. If so then maybe a better way to handle
this is to run a check against the overall client disk msg block for the
string pattern of "Mounted on" instead. Change do_disk.c section:

else if (strstr(msg, "Filesystem")) dsystype = DT_NT;
else dsystype = DT_UNIX;

to

else if (strstr(msg, "Filesystem")) dsystype = DT_NT;		/* This
will trigger for Windows and Unix/Linux flavors */
else if (strstr(msg, "Mounted on")) dsystype = DT_UNIX;	/* Assuming all
unix/linux/BSD clients report with "Mounted on" and Windows clients only
report with "Mounted" in their header line */