We often have to deploy text files. Version control is a challenge so we write our relevance so that we look at the modification time of the file. We do get quite a large number of failures, not because the file did not get deployed correctly but there seems to be an inconsistency in how the timestamp is handled.
Below we are returning the modificaiton time of the files but one system is giving us an earlier time stamp. Both systems have the exact file. Maybe lookin at the timestamp is not such a good idea ?
Any suggestions ?
q:modification time of file “OTMRES.lnk” of folder “r:\webstation\Setup\Bin\Kiosk\SalesFlr\Deskback”
A: Sat, 20 Jul 2013 12:06:22 -0500
T: 739.956 ms
q:modification time of file “OTMRES.lnk” of folder “R:\webstation\Setup\Bin\Kiosk\SalesFlr\Desktop”
A: Sat, 20 Jul 2013 12:06:22 -0500
T: 509.903 ms
q:modification time of file “OTMRES.lnk” of folder “q:\webstation\Setup\Bin\Kiosk\SalesFlr\Deskback”
A: Sat, 20 Jul 2013 13:06:22 -0500
T: 988.707 ms
q:modification time of file “OTMRES.lnk” of folder “q:\webstation\Setup\Bin\Kiosk\SalesFlr\Desktop”
You are correct about the time zone changeing affecting the offset. And the universal time should be constant but in my case it is not. You can see in my example where the hour changes. That is ok but the offset value did not change… That is not OK.
I deployed some files. In my relevance statement the action was successful if the following evaluated to false
modification time of file “OTMRES.lnk” of folder “c:\webstation\Setup\Bin\Kiosk\SalesFlr\Deskback” < “Sat, 20 Jul 2013 12:06:22 -0500” as string as universal time.
About half the targets failed… I put the correct file in the corret location but when it was evaluating the file the time stamp was an hour later…
Sat, 20 Jul 2013 13:06:22 -0500
It would have been fine if the offset had been -0600 but it was not. I do agree that universal time should be constant but it appears to be somewhat of a moving target.
The files in question do not get altered. They are just lnk files that display an icon on a desk top. When a failure is encountered the time stamp is off by exactly one hour… Always later. Seems BigFix has an issue coming up with the correct offset value sometimes…
You are correct about the time zone being a mitigating factor but the time stamp when converted to udt should all resolve to the same value, at least that is how I percieve it…UDT timestamp, sha1 and size should be constant values.
modification time of file “C:\unzip.exe”=“Sat, 15 Apr 2000 23:55:10 -0500” as string as universal time is a true statment
modification time of file “C:\unzip.exe”=“Sat, 15 Apr 2000 22:55:10 -0600” as string as universal time is a true statement.
modification time of file “C:\unzip.exe”=“Sun, 16 Apr 2000 04:55:10 -0000” as string as universal time is also true
All three examples represent the same UDT time.
But in my problem the time stamp is off by an hour but there is not corresponding change in the offset value. The time stamp should be a constant UDT time value… The hour and and even the day could change but the offset value should change accordingly. At least that is my view of how it should work… But it’s no working that way consistently.
I now see what you are saying, in my haste I didn’t notice that the time zone offsets were all -0500. That does make this interesting. Is the time difference always exactly 1 hour, or is it random?
Also, is it random files or the same ones?
When the files are laid down initially, are they the correct time stamp? Or is it wrong from the beginning?
Lastly, if you can try using Procmon from sysinternals to monitor the file for modification attempts and track down what is the cause of the time stamp differences.