Checking from a central location out to a couple thousand computers, the Visual Basic .NET (written using Visual Studio Express 2012) can't be trusted to get the latest time stamp. I wrote the following function and this issue arises specifically when using the Mod.
Shared Function GetFileInfo(ByVal ComputerName As String, _So, it should be no problem, right? Wrong. Even with the fi.Refresh() in there, it still brings back an outdated time stamp. You could go to Windows Explorer and UNC to the remote computer, browse to the file and right-click, bring up the properties and see the correct time stamp. Oddly enough, after you do THAT, the above function gets the right time stamp! Sometimes the difference between the two can be days!
ByVal FiletoFind As String, info As String)
Dim Ret As String = ""
Dim targetfile = "\\" & ComputerName & "\" & FiletoFind
Dim fi As FileInfo = New FileInfo(targetfile)
If fi.Exists Then
Select Case info
Case Is = "Exists"
Ret = fi.Exists.ToString
Case Is = "Delete"
Ret = fi.Exists.ToString
Case Is = "Created"
Ret = fi.CreationTime.ToString("MM/dd/yyyy hh:mm:ss tt")
Case Is = "Access"
Ret = fi.LastAccessTime.ToString("MM/dd/yyyy hh:mm:ss tt")
Case Is = "Mod"
Ret = fi.LastWriteTime.ToString("MM/dd/yyyy hh:mm:ss tt")
Ret = "File Not Found"
Ret = Ret.Replace(vbCrLf, "")
Ret = Ret.Replace(vbCr, "")
So, I went to AutoIT3 and ... okay, I already had the code to check the files I wanted...
Func _FileTimeStamp($path)The AutoIT3 code gets the right time stamp and makes the VB accessed 'ghost data' update.
$file = $path
$astamp = FileGetTime($file, 0, 0)
If IsArray($astamp) Then
$stamp = $astamp & "/" & $astamp & "/" & $astamp & " " & _
$astamp & ":" & $astamp
ElseIf $astamp = 0 Then
$stamp = "file not Found"
$stamp = 0
The reason to get the time stamps is to make sure that the Tuner is functioning as expected. Too often, it is not. So, WHEN a Tuner has an outdated channel, I wrote a little function to go through a little process that usually fixes the problem.
Private Sub UpdateChannelFix()The program finds the path to Tuner.exe by looking in the registry for the Application entry. Using that, the function uses Tuner.exe to stop the Patch and Inventory channels, which can sometimes get stuck in a running state and cause issues. Then, it uses the Runchannel.exe program in the same folder to do a reset on the Patch channel. The -subscribe makes sure that if the channel is not present, it will install it. Then it updates or subscribes and runs the Infrastructure, Inventory and Subscription channels. Running the Inventory channel will usually run the Patch channel as well.
Dim runchannel As String = TunerPath.Replace("Tuner.exe", "Runchannel.exe")
Dim Procedure(5) As String
Procedure(0) = "Tuner,-stop http://MyBMCServer.Mycompany.local:5282/Marimba/Current/PatchService"
Procedure(1) = "Tuner,-stop http://MyBMCServer.Mycompany.local:5282/Marimba/Current/InventoryService"
Procedure(2) = "Runchannel,-subscribe http://MyBMCServer.Mycompany.local:5282/Marimba/Current/PatchService -reset"
Procedure(3) = "Runchannel,-subscribe -update http://MyBMCServer.Mycompany.local:5282/Marimba/Current/InfrastructureService"
Procedure(4) = "Runchannel,-subscribe -update http://MyBMCServer.Mycompany.local:5282/Marimba/Current/InventoryService"
Procedure(5) = "Runchannel,-subscribe -update http://MyBMCServer.Mycompany.local:5282/Marimba/Current/SubscriptionService"
For Each pStep As String In Procedure
Dim rp As Process = New Process
Dim rpi As ProcessStartInfo = New ProcessStartInfo
Dim parts = Split(pStep, ",")
Dim mExe As String = parts(0)
Dim mCmd As String = parts(1)
rpi.WindowStyle = ProcessWindowStyle.Hidden
If mExe = "Tuner" Then
rpi.FileName = TunerPath
rpi.FileName = runchannel
rpi.Arguments = mCmd
rp.StartInfo = rpi
Catch ex As Exception
' oops, nevermind - will catch it in examination
AlertText = AlertText & vbCrLf & mExe & " " & mCmd & _
" <-- Failed to run"
Cool, huh?!? :)