In trying to determine the age of the command file on a Radmind client — in this case, a Mac OS X 10.5 Leopard system — I learned that its modification date is the same as on the server. This is true on multiple clients I examined, so I believe it to be both consistent and intentional. It also makes sense.
What timestamp, then, can you use to determine how old your command file is, or when your client last updated?
Let’s look into this. For example, here is the command file on a client:
[RadmindClientA]$ ls -ul /private/var/radmind/client | grep command.K
-rw-r--r-- 1 root wheel 667 Jun 3 05:30 command.K
[RadmindClientA]$ ls -cl /private/var/radmind/client | grep command.K
-rw-r--r-- 1 root wheel 667 May 29 10:28 command.K
[RadmindClientA]$ ls -l /private/var/radmind/client | grep command.K
-rw-r--r-- 1 root wheel 667 May 29 10:21 command.K
And the same file examined on the server:
[RadmindServer]$ ls -ul /private/var/radmind/command | grep selected-client-command.K
-rw-r----- 1 root wheel 667 Jun 3 05:27 selected-client-command.K
[RadmindServer]$ ls -cl /private/var/radmind/command | grep selected-client-command.K
-rw-r----- 1 root wheel 667 May 29 10:21 selected-client-command.K
[RadmindServer]$ ls -l /private/var/radmind/command | grep selected-client-command.K
-rw-r----- 1 root wheel 667 May 29 10:21 selected-client-command.K
The status change time (ls -cl) is a little bit harder to understand. I’ve seen it minutes apart from the modification time on a client, but it is the same as the modification time when viewed on the server.
The access time (ls -ul) of the command file on the client, however, simply corresponds to when ktcheck last ran.
For good measure, another client:
[RadmindClientB]$ ls -ul /private/var/radmind/client/ | grep command.K
-rw-r--r-- 1 root wheel 1188 Jun 5 05:08 command.K
[RadmindClientB]$ ls -cl /private/var/radmind/client/ | grep command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:13 command.K
[RadmindClientB]$ ls -l /private/var/radmind/client/ | grep command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:09 command.K
And its command file on the server:
[RadmindServer]$ ls -ul /private/var/radmind/command | grep another-selected-client-command.K
-rw-r--r-- 1 root wheel 1188 Jun 4 05:13 another-selected-client-command.K
[RadmindServer]$ ls -cl /private/var/radmind/command | grep another-selected-client-command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:09 another-selected-client-command.K
[RadmindServer]$ ls -l /private/var/radmind/command | grep another-selected-client-command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:09 another-selected-client-command.K
I looked into this because I was wondering why ktcheck -C (to “clean” the /private/var/radmind/client directory) wasn’t having the effect I expected. I thought it cleared out the client directory and started with fresh files, which would all have new timestamps because they were new to the client. When I didn’t get the new timestamps I anticipated, I worked through what I saw until I settled on this explanation.
The result? The main means you have of determining whether the command file has been updated is its access time. The access timestamp corresponds with the date and time of the last ktcheck action. This appears to be the case no matter which flags I’ve used with ktcheck — even with ktcheck -n (where “no files are modified”).
The modification time, for all intents and purposes, only indicates when the file was last changed on the server. Testing this out — with command files that have been overwritten with the exact same contents (using cat), as well as command files deleted on the client before ktcheck — I have reached the conclusion that the modification time changes only when the file contents do.
So, I don’t have solid explanations for all of this. But, I’m now armed with the knowledge that the access timestamp is the most important when you’re looking for the age — or at least the last refresh time — of a Radmind client’s command file.