That did it jgstew, thank you so much! And thanks gearoid for your suggestions. Final relevance pasted at bottom.
I adapted the relevance for Windows machines, but theyāre returning a Windows error:
The process cannot access the file because it is being used by another process
As these are log files they are always going to be āin useā by the Crashplan application. Any way around this? I did a search on the forum and couldnāt find anything. I presume this problem happens with many log files
Thanks
if not exists file "/Library/Logs/CrashPlan/history.log.0" then "Not Installed!" else if not(content of file "/Library/Logs/CrashPlan/history.log.0" contains "Starting backup to ") then "Backup Never Started!" else if not(content of file "/Library/Logs/CrashPlan/history.log.0" contains "Completed backup to ") then "Backup Started but Never Completed" else maxima of ( (it as date ) of ( ((it as integer as string) of preceding text of last "/" of following text of first "/" of it ) & " " & (preceding text of first "/" of it as integer as month as three letters)& " " & "20" & (following text of last "/" of it as integer as string)) of preceding text of first " " of following text of first "I " of it) of lines whose (it contains "Completed backup to") of files whose (name of it as lowercase contains "history.log.0") of folders "/Library/Logs/CrashPlan" as string
Did you try it through the fixlet debugger, or the console, or both?
For Log Files, sometimes it works through the console, but not the debuggerā¦ other times it is the opposite.
I think your relevance is a bit more complicated than it needs to be and could be simplified. It would also be better split up into multiple analysis properties. It is also asserting the wrong thing in some cases, like āNot Installed!ā, which really should be āNo Logsā
I would break up the analysis properties like this:
Number of Log Files
number of files whose(name of it as lowercase contains ".log.") of folders "/Library/Logs/CrashPlan"
Number of Log Files that can be read
number of files whose(name of it as lowercase contains ".log." AND exists lines of it) of folders "/Library/Logs/CrashPlan"
At Least one Backup Started?
exists files whose(name of it as lowercase contains ".log." AND (content of it) contains "Starting backup to ") of folders "/Library/Logs/CrashPlan"
At Least one Backup Completed?
This is redundant with the property below.
exists files whose(name of it as lowercase contains ".log." AND (content of it) contains "Completed backup to ") of folders "/Library/Logs/CrashPlan"
Most Recent Backup?
maxima of ( (it as date) of ( ((it as integer as string) of preceding text of last "/" of following text of first "/" of it ) &" "& (preceding text of first "/" of it as integer as month as three letters)&" "& (following text of last "/" of it as integer as string)) of preceding text of first " " of following text of first "I " of it) of lines whose (it contains "Completed backup to ") of files whose(name of it as lowercase contains ".log.") of folders "/Library/Logs/CrashPlan"
All of the above properties can actually be combined into a universal analysis for Mac & Windows with the following:
number of files whose(name of it as lowercase contains ".log." AND exists lines of it) of (folders "/Library/Logs/CrashPlan"; folders "path\to\windows\crashplan\log\location")
I tried both. I presume (like with many log files) the process keeps the file open. Is there no way around this in Bigfix? One would presume there are so many cases where log files are kept always open.
Thanks for the suggestion to break up the analysis. I have done that now
That is surprising - the agentās inspectors should be able to read.
Can you read those files from something else on those same computers or maybe thereās something a little different about their access rights ?
What OS are you on?
Yes, it would be nice if Bigfix could just read the files. They have full permissions for admins and regular users. If the command promppt (in non admin mode) can read the files (e.g. using the ātypeā command), then Bigfix certainly should. Reckon I should log a case with IBM?
Iām using Windows 8. Full perms to admin and regular users alike for the log files. I can read the files in command prompt (in non admin mode), using for example the ātypeā command, as in:
Not a bad idea. There should already be an RFE about this, but filing a PMR isnāt a bad idea. I think the BigFix client is being too hands off of the file that is open but not locked by another process.
I canāt believe there isnāt a āfile for readingā, āread only fileā or other type of property that would only do a read access to a file that is in use by another user (system log files)!? It makes me feel like Iām back in the 90ās! In my opinion, this issue makes IBM/BigFix seem a bit outdated. This is something that should have been addressed.
For those of you that want to make this happen, here is the RFE that appears to address the file locked issue.
Whatās particularly frustrating is that I have been talking indirectly to the Bigfix
developers and they insist the problem is a feature! They insist itās for our own good which I donāt accept for a second.
Their reasoning: āWhile the file may be opened allowing other applications
read access, BESClient will not open a file for inspection that is opened
by some other application with write access.
This is intentional, to avoid the file being changed while BESClient is
examining it. The result of inspecting a file that is in the process of
being changed by another application is unpredictable.ā
They are saying that even though the parent program explicitly says āHey,
everyone can read this file, Iām giving you all permission!ā, and even
though I would have no problem if I could just read this file, they feel
that us customers still shouldnāt be able to read the file for our own good
to protect us from our own errors. That seems condescending and it just
doesnāt make sense as in the majority of use-cases this would not be a
problem. In a billion other ways, Bigfix gives you the freedom and power to
make our own decision whether or not this causes an issue. In addition,
there are ways to tell if a program is currently writing to a file, which
would avoid the above concern. On Mac and Linux, I can read all files from
Bigfix, and I also have an identical use-case on Macs which can read the log file fine, no problems ever. I still donāt accept this as a good answer. It seems like
IBMās excuse to do nothing instead of address a valid problem - unless Iām
missing something in their explanation.
I can see an argument for their āfeatureā, but I am calling BS on two accounts:
This feature is not present in any other OS supported. One of BigFixās major issues (in my opinion) is the lack of continuity between OSās.
It shouldnāt matter if the file is changed as you are reading it or immediately before or after you read it. The point of the fixlet is to get the state of the file at the time it is evaluated. Not 2 seconds ago, not in 2 seconds. Read the file and return the results for the nano-second it was read.
Sorry for the soap-box. I canāt stand it when the vendor calls something a āfeatureā that the majority of end users call a ābugā.
I can see their reasoning for this being the default behavior, but there should be a way to override the behavior using an inspector where you except the consequences of reading a file that is opened for writing.
If waiting for the next BES version & hoping it sorts this out is not an option for you, what I generally do is take a Policy Action each night to create a backup copy of the log file that I want to inspect, then have the Analysis inspect the backup copy. The Action just does something like dos copy /y c:\log.txt c:\log.bak. Not elegant, but itās at least enough to check once daily that the previous nightās backup was successful.
Was and RFE ever created for being able to analyze a busy file with relevance? I am getting the āclass fileIOerrorā trying to run an analysis against a file.