FEATURE REQUEST: filter by "today" in check_files

[lgmu]

It would be great to have something like this:

check_files path="C:\" pattern="*.xyz" filter="written >= today" crit="count gt 0"

I'd expect "today" to be 00:00 of the current day.
Sometimes you only care about files which were created/ modified today and not like 24h ago, so this would be more accurate.

[inqrphl]

Looking into the code, the condition checks are written into a snclient.Condition.

Sending a query like this

check_files ' path="/tmp/snclient-test/"  ' ' filter="written>today" '

At condition.go:324 the debugger gives me these values

*snclient.Condition {noCopy: snclient.noCopy {}, keyword: "written", operator: Greater (13), value: interface {}(string) "today", unit: "", group: snclient.ConditionList len: 0, cap: 0, nil, groupOperator: 0, isNone: false, original: "written>today", attr: .......}
varStr: "1762351518"
varNum: "1762351518"
condStr: "today"
condNum: "0"

This function uses the correct attribute name "written" to acquire it from data. The condition wants the data to be compared to "today", and when its parsed into a float as well it gets value

The easiest fix would be to realize that "today", "tomorrow", "yesterday" etc. keywords should specially parsed into a float value just like the "version" keyword. This is already done directly above.

I do not really like this approach.

• At that function in the code, you do not have access to the check you are running.
• If I just treat "today" string specifically and convert it to the UNIX timestamp at 00:00. It then works with the numerical comparisons like Greater, Lesser. and LesserEqual, and the above case with "check_files" would work.
• If user performs another check with a numerical comparison filter, I would be converting "today" into a float blindly. I should have thrown an error since using "today" in that check is nonsensical, but I cant discriminate based on the check I am running.
• If the comparison filter uses an operator like Equal or Unequal, the code tries comparing numerical values if parsing was successful, or does a string compare if parsing was unsuccessful. Converting "today" and marking the parse as successful might cause problems with this.

The correct fix should be aware of the check its running. Convert keywords like "today" early on depending on the check and modify the Conditional object, or construct it properly from the beginning.

[inqrphl]

I implemented a function at the end of checkdata:parseArgs. It functions like other TransformKeywords functions, and transforms the values for check functions. I think thats the most logical and least invasive place to put it.

total 0
-rw-rw-r-- 1 ahmet ahmet 0 Nov  5 12:00 today
-rw-rw-r-- 1 ahmet ahmet 0 Nov  6  2025 tomorrow
-rw-rw-r-- 1 ahmet ahmet 0 Nov  3 12:00 two_days_ago
-rw-rw-r-- 1 ahmet ahmet 0 Nov  4 12:00 yesterday

check_files ' path="/tmp/snclient-test/"  ' ' filter="written>one_month_ago" '
OK - All 4 files are ok: (0 B)
check_files ' path="/tmp/snclient-test/"  ' ' filter="written>one_week_ago" '
OK - All 3 files are ok: (0 B)
check_files ' path="/tmp/snclient-test/"  ' ' filter="written>yesterday" '
OK - All 3 files are ok: (0 B)
check_files ' path="/tmp/snclient-test/"  ' ' filter="written>today" '
OK - All 2 files are ok: (0 B)
check_files ' path="/tmp/snclient-test/"  ' ' filter="written>tomorrow" '
OK - All 1 files are ok: (0 B)