Using the following relevance statement but it is returning incorrect information. Just trying to return the size of the folder “windows”.
((sum of sizes of descendants of folder "windows" of drive of system folder)/(1024*1024*1024)) as string & " GB"
I would expect the value to be returned for my testing system to be 37GB however the query returns 22GB. Tried other folders other than just the windows folder and it always returns values that I would not expect. Any thoughts on what I would be missing here? Seems like such an easy task.
Could be a few things throwing the calculation in the Windows directory, including perhaps Directory Junctions / Symlinks, or directories or files that LocalSystem cannot access.
You’d probably need to go down folder by folder and see what doesn’t match your expected sizes, to determine why they differ
So it does seem like files that LocalSystem doesn’t seem to have access to. Is there any way around this to gather the size? I have been playing around with a relevance to gather the total size of the C drive and then just exclude the Windows folder. Having a bit of difficulties getting that to return proper output though - here is what I have?
((sum of sizes of descendants of it whose (pathname as lowercase does not contain “windows”) of drive of system folder) / (102410241024)) as string & " GB
You are using the QNA mode of the debugger which is running as your user account so will be restricted by whatever access control are in place against your account. The query would actually run as SYSTEM so may not encounter the same restrictions, but any folder not accessible to SYSTEM will suffer the same fate.
QNA does not have a time limit for getting a result from a relevance statement. The agent does have safety feature that would prevent a query from running for numeric minutes and locking out the agent. I don’t know of recent limits but I do recall year back it was mentioned that a 10 second hard limit was applied to the agent. This would mean your query, when processes as a property, would be unlikely to complete so you will not see results.
Your safer approach may be to use a task to execute a PowerShell command to total up the file sizes, output to a text file then have Bigfix read the text file. One possible method you can maybe build on, and they may be many depending on your use case and environment,
You could do it in batch as well. Way back, wrote a batch script for a school district I worked for. Teacher could not see their hidden files and did not know why they ran out of space on their drives.
@SLB 's PS option above is probably your best bet. You can also dump it to a registry key and pull it into a property or analysis.
If you want the batch version, let me know and I will see if I can find it. It does take a minute or two to run depending on size.
Hi @mattgarrett1981, you can check to see if filesystem redirection is causing this discrepancy and below I’ve slightly modified your client relevance to use x64 folder vs x32 folder so you can see the difference from my endpoint. These client relevance statements can consume plenty of resources given that you’re using descendants of folders. Therefore test and validate before deploying this analysis property to all your endpoints:
Q: (sum of sizes of descendants of x64 folder (pathname of windows folder)/(1024*1024*1024)) as string & " GB"
A: 42 GB
T: 67200.655 ms
I: singular string
Q: (sum of sizes of descendants of x32 folder (pathname of windows folder)/(1024*1024*1024)) as string & " GB"
A: 39 GB
T: 67365.918 ms
I: singular string
