Windows 7: Setting and Maintaining Accurate System Time

I wanted to keep two computers' clocks set the same, for purposes of synchronization, so that they would have an accurate sense of whether the version of File X on computer A was newer than the version of File X on computer B.  I had previously installed (or, more accurately, just added a copy of) Judah Levine's portable NISTIME 32 in something of a rush, when installing Windows 7, and, later, had vaguely recognized that it was not working right and/or I had not set it right.  Now I decided to work out the kinks in this function.

NISTIME-32BIT.EXE

I started with the National Institute of Standards and Technology (NIST), from which programs like NISTIME 32 would draw the current time.  It developed that NIST had a program called nistime-32bit.exe.  It turned out to be the same as NISTIME 32, just slightly updated.  The webpage's instructions were to start by going into File > Select Server and then Query Server > Now.  Somewhere I saw advice to choose a server near me.  I was tempted to choose two different ones, one for each computer, so as to have accurate time in case there was some terrible disruption of the national timekeeping system.  Then I realized that this could have the effect of making rivers run upstream, where my files were concerned, to wit:  new could be replaced by old.  Being up-to-date on the latest developments in American chronology suddenly seemed less important than making sure I didn't accidentally overwrite today's crossword puzzle.

When I went to the Query Server > Now menu pick, I got a dialog indicating that NISTIME 32 was prepared to adjust my computer by 0.953 seconds.  I told it to go ahead.  I also went into Query Server > Periodically and told it to update the computer every 12 hours.  Query Server > Server Status confirmed these settings.  File > Help in Choosing Dirs told me to hit File > Save Config to save my settings.  This gave me "File Error:  Cannot open file to save configuration."  That problem may have been caused by nesting the program too deeply in a subfolder.  I moved it elsewhere and tried again. Now it seemed to confirm that it had saved my settings, and it created NISTIMEW.CFG in the same folder as the program's portable executable (nistime-32bit.exe).  I exited and restarted, and it remembered what I had told it.  But I had to remember to hit File > Save Config; it would not remember anything.

But then, when I did go into Query Server > Periodically, specified 12 hours, and hit File > Save Config and then File > Exit, I could not get it back.  The program refused to become visible.  I tried a couple of times, and then looked at Windows Task Manager (Start > Run > taskmgr.exe) > Processes tab.  Taskmgr showed four separate instances of "nistime-32bit.exe *32."  I selected them and clicked End Process, one by one, and then ran nistime-32bit.exe again.  It returned to taskmgr.exe, but not to the screen.  I minimized all windows, one by one, but, no, it was not lurking anywhere.  There didn't seem to be a taskbar or system tray icon for it.  It was here, and yet not here.  I killed the processes again, now that I had started one or two new ones.  I renamed NISTIMEW.CFG to be something else, and now it would start, and it saved new settings in a new NISTIMEW.CFG.  Apparently the config file had gotten corrupted.  I had originally created that file manually in lowercase (nistimew.cfg); possibly something about the program needed the uppercase filename.

But now, same thing again.  Exiting and restarting gave me a hidden program:  visible in Task Manager's Processes tab, but not visible onscreen.  When I right-clicked on nistime-32bit.exe *32 in Task Manager and selected Properties, I got an error:  "Windows cannot find [pathname] nistime-32bit.exe."  I ended the process again.  I created a shortcut to the .exe and tried starting it that way.  I had no reason to think that would make any difference, and in fact it didn't.  I tried moving all of the files from the folder where I had put nistime-32bit.exe, and placed them all instead in C:\Windows, with a shortcut to the executable in my Start Menu.  That wasn't the answer; I still got lurking program sessions that appeared in Task Manager but nowhere else.  I deleted the CFG again and tried again.  Now it ran.  I went directly to File > Save Config without making any changes.  It indicated that it had saved the config file.  I exited and restarted the program.  It ran.

Now I saw something that may have explained the config file problem.  The server list had changed.  The Colorado server that I had selected previously was no longer listed in File > Select Server.  I had previously gone into File > Update Server List, and that had generated a message:  "New server file is C:\Windows\NIST-SRV.LST."  It did that again now, when I designated a new server.  I hit File > Save Config and then File > Exit, and then restarted the program.  Now it was running normally.  I moved the three files (the exe, cfg, and nist-srv.lst files) from C:\Windows back to the folder where I really preferred to have them.  It seemed that the server list had not properly updated when the files were in that folder originally.  I restarted and went through the same steps -- update server list, choose a new server, save config -- and now I was exiting and restarting without a problem.

But no, I spoke too soon.  When I restarted, saved a 12-hour periodic refresh, and exited, it would not restart.  Deleting the config and moving the other files back to C:\Windows did not fix it.  The problem seemed to relate specifically to the attempt to set up recurrent time checks.  I was doing something wrong, or perhaps the program had a bug, or maybe it was not suited for 64-bit Win7.  I went to the NIST webpage cited in the program's Help > More Help and sent an email to the Webmaster link at the bottom of that page, pointing them here.

The Built-In Windows Time Sync Option

I decided to look for an alternative time-updating program.  I ran a search and discovered that there was apparently some kind of automatic time-updating arrangement built into Windows.  The advice there was, however, that "The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs."  That was consistent with the fact that my two computers' timeclocks tended to be somewhat inconsistent with one another.  I had not tried to see how inconsistent they could be, or how long they could remain that way.  I did see an indication somewhere that Windows defaulted to a weekly time update, so maybe it would verify that it was accurate to within a minute, or something, every week or so.

That appeared to be steered by Control Panel > Date and Time.  That dialog could also be opened by right-clicking the clock in the system tray and choosing Adjust Date/Time.  Or, as I now learned from Eric Phelps, it could also run from the command line via "rundll32.exe shell32.dll,Control_RunDLL timedate.cpl."  The latter option would facilitate the option of opening the Date and Time dialog for manual adjustment via, say, a batch file that would open it automatically (to the correct tab) every day, week, or whatever.  (Later, I found a How-To Geek webpage that said I could just run "w32tm /resync" as administrator to resynchronize the clock without even going into the Date and Time dialog.  That, too, could be incorporated into a scheduled batch file.)

The Date and Time dialog > Internet Time tab > Change Settings option gave me a choice of synchronizing with time.nist.gov, which I understood to be the most accurate (though others in that list, not counting time.windows.com, appeared to be cousins of NIST).  I noticed that the dialog told me, here, that "This computer is set to automatically synchronize on a scheduled basis."  The previous sync site, as I saw on the other computer, was time.windows.com."  I wasn't sure how synchronizing with that site could have left my two computers with different times -- differing by seconds, that is, not by minutes -- unless maybe time.windows.com was just not that worried about the seconds.  Or maybe it was trying to synchronize when my router was doing its daily self-restart, and was therefore not getting access to the online clock?  I wasn't sure.  (Note:  Fouzan said that this whole process wouldn't work if the computer was on a domain.)

Curious about the timing, I went into Start > Run > taskschd.msc > Task Scheduler Library.  There were maybe 15 items in the list, and none of them were obvious time sync tasks.  So another possibility was that some bug or tweak, brought into my system somewhere along the line, was preventing the creation or execution of the scheduling function.  Another emerging possibility was that, as stated in a How-To Geek webpage, time.windows.com (which my systems had been using by default) had "a ton of problems with uptime."  So possibly I had already fixed my problem, just by switching the machines to use time.nist.gov in the Date and Time dialog.  (I did notice, as soon as I made that switch and clicked the update button, that both computers' clocks showed exactly the same time.)

Other Possibilities

I ran another search and found a Gizmo recommendation for Dimension 4 as a time correction utility.  It occurred to me, at this point, that possibly I had fixed my problem, just by switching away from time.windows.com (above), and that maybe I should just let things slide for a week or two.  I decided mostly just to record some notes, here, for possible future reference.  So instead of installing Dimension 4, I just dragged the icon for its webpage from my browser's Address bar over to the Time subfolder in my customized Start Menu.  If I ever needed it, I could follow the link at that time.

There also appeared to be more to know than I had realized, regarding Task Scheduler (taskschd.msc).  In Task Scheduler's left-hand pane, I went down the tree into Task Scheduler Library > Microsoft > Windows > Time Synchronization.  Now I saw that my machine was indeed set to synchronize time at 1 AM every Sunday.  I saw advice from Tina Sieber on a way to adjust and improve the scheduling via Task Scheduler.  Tina seemed to believe, however, that using a separate program might be the simpler and more accurate approach.  Tina pointed toward two other programs, Atomic Clock Sync and AtomTime.  The webpage for the latter seemed very old.  I was not sure how it would fare in a 64-bit Windows 7 world.

For now, the solution seemed to be simply to go into the system's clock and change its time source to NIST.  My monthly batch file brought up the NIST/USNO timepage on the first of every month, so I could observe, later, whether my two computers were again diverging from one another and/or from the time on that webpage.  If they didn't stay in line, I would have two options.  One would be to add one of the foregoing command lines to my daily or weekly batch files, to permit manual and/or automatic checking and/or resynchronization.  Another would be to try one of the several freeware utilities just mentioned, particularly Dimension 4 or Atomic Clock Sync.

Windows 7: Verify That Data Files Are in Working Condition: JPG, MP3, PDF

I wondered if there was a way to test my data files, to make sure they would actually open without errors.  I posted a question on it, but that didn't get too far.

Eventually, I did find a couple of ways to test JPGs and other image files.  IrfanView was my favorite tool for this purpose.  I decided I wasn't really too concerned about corrupt spreadsheet and document files, since I rarely encountered anything like that.  I was in the habit of converting my documents into PDFs for storage.  JPGs, MP3s, and PDFs were probably the most numerous file types on my system, so I decided to focus on those for now.

For MP3s, a search led to a thread that identified a number of possible testing utilities.  I ran a search for several (i.e., MP3 Checker and Mpck, MP3 Diags, MP3Utility, and MP3 Validator) and came away with a preliminary impression that MP3 Diags and MP3Val were relatively popular.  None seemed to be listed on CNET.com, but I found MP3 Checker (2,111 downloads), MP3 Diags (3,387 downloads), and MP3val (1,925 downloads) on Softpedia.  It looked like MP3 Diags was being actively developed and had relatively good file correction possibilities, so I downloaded that.  The developer warned of potential data loss, so I decided I wouldn't necessarily use it to edit any MP3s until I was in a position to test them after the changes and make sure things had gone OK.  I ran it on a folder containing about 120 MP3s.  It ran for just a minute or so and identified problems with various songs (e.g., certain tags not found, low quality, two ID3V1 tags found when there should be no more than one).  It made these errors graphically visible, so that I could quickly see which files had the more worrisome kinds of errors (e.g., "Unknown stream found.  Since other streams follow, it is possible that players and tools will have problems using the file.)  In short, I liked MP3Diags.  Granted, I had not used it to fix anything.  But it made a good impression.

Now, how about testing PDFs?  A search did not yield much immediate help.  (A different search, later, was a whole different story, but I didn't get that in time for this.)  One suggestion was to automate printing them and see which ones printed.  It would have been possible to copy them all from various subfolders to a single subfolder, assuming duplicate names had first been resolved using something like DoubleKiller.  A Windows search would achieve this; so would a batch command using XCOPY.  From there, I could batch print to other PDFs, and perhaps the printing process would identify bad files.  I wondered whether an IrfanView conversion (as used in JPG testing) would do the same thing.  I tried opening a PDF in IrfanView and got an error:

Decode error !
Can't load Ghostscript or Ghostscript error.
Install Ghostscript from:
http://sourceforge.net/projects/ghostscript/
or
http://sourceforge.net

The latter appeared to be the current master site for Ghostscript.  I thought I did already have it installed, but perhaps not the latest version.  I tried using Irfanview (File > Batch Conversion/Rename) to convert several PDFs to JPGs, but got an error that way too:  "Error!  Can't load [filename].pdf."  To update Ghostscript, I downloaded and installed what looked like the Windows 32-bit version.  I tried the Irfanview conversion again, and that worked.  So it wasn't going to be necessary for me to explore the alternative of using PDFtoHTML, which would apparently require me to install Windows versions not only of Ghostscript and PDFtoHTML but also PDF2HTMLgui, which looked like it might be hard to find -- never mind the alternative of installing Xpdf, apparently an alternative to Ghostscript, or the approach of installing some relevant program (PDFtoHTML, I think) via GnuWin, which was going to be simplified by installing GetGnuWin.

Fortunately, I didn't even have to think about all that.  I just ran an IrfanView batch process on a bunch of PDFs.  To test if this was going to work properly, I inserted a bad PDF among those being processed.  To create a bad PDF, I searched for a hex editor, downloaded HexEdit, opened a copy of a small PDF file, looked in the ASCII pane (the right-hand one, in HexEdit; the one with occasional text rather than all numbers) for a reference to Root ## 0 R. (in my case, it was Root 9 0 R.), and change ## to 00 (so in my case, it came out being Root 00 0 R.), and then saved and tried it out.  Sure enough, when I tried to open the bad PDF, I got "There was an error opening this document.  The root object is missing or invalid."  So now I ran an IrfanView batch conversion of PDF to JPG, including that bad file (putting the output in a folder called X, which would cue me that I could delete the whole thing without looking at it).  Of the four files I tried to convert, three converted OK.  The bad PDF gave me an error in IrfanView and nothing in the output folder.  So then I would be able to just save the IrfanView report and examine the error messages; or if that failed, I could hunt around for a suitable folder comparison tool, or use a spreadsheet to compare folders, so as to work up a list of the PDFs that had failed the conversion process.

The spreadsheet approach, used with a command line process, might be best for those situations where the files I wanted to test were scattered across multiple folders.  What I would want, in that case, would be the ability to execute a batch command containing commands of this general form:

convert D:\Folder1\File35.pdf to D:\TestFolder\File35.jpg
convert D:\Folder2\File18.pdf to D:\TestFolder\File18.jpg

A problem there was that File35.jpg might already exist in TestFolder.  This could happen because there could be files named File35 in two different source folder, and now that would become evident when I tried to put them both (in JPG format) into one target folder.  One way to avoid that would be to begin with a DoubleKiller search for JPGs with duplicative names (having previously done a DoubleKiller search for files of any sort that had identical sizes and CRCs).  Alternately, I could test my spreadsheet-generated commands to see if they were going to produce duplicate filenames, and add a formula to change them as needed.  As for the "convert" part of that ideal command (above), I posted a question in the IrfanView forum, and then found a suggestion that the command I wanted would be like this:

i_view32 D:\Folder1\File35.pdf /c=d:\TestFolder\File35.jpg 

They said this (specifically, the "c=" option) would work to convert among all formats that IrfanView could handle except AVI, MOV, MPG, WAV, and MID.  (There would presumably have been PATH problems if I'd been running the portable version of IrfanView; the command line presumably wouldn't have known where to look for a non-installed program executable.)  Later, in response to the question I posted, someone said that, of course, I should have just gone into IrfanView's F1 (Help) > Contents tab > Overview > Command Line Options.  Which, when I finally did that, wow, there were a lot of them.  That help piece began with the advice to "See the 'i_options.txt' (IrfanView folder) for the most recent version of all command line options."  That file said I could use "/convert=" rather than just "/c=" and also that I should "See pattern help file page for more options."  At first, I thought that referred back to the F1 help page I had just come from; it had some conversion examples.  Those examples seemed mostly to show how I could include other command-line options at the same time.  One interesting option:  /filelist=txtfile would apparently use filenames contained in a file called "txtfile," so that apparently I would not have to repeat this command in full (on the command line or in a batch file) for each file being processed.  It said the conversion command would support wildcards.  Then I noticed that the pattern page was actually in a different place in IrfanView help:  it was under Options Menu > Text/Pattern Options.  There were variables or "placeholders" for a variety of components (e.g., $D was shorthand for the full path of the file being converted).  This seemed to mean that a command like "i_view32.exe d:\Folder1\*.jpg /c=d:\$D$N.pdf" would convert all the JPGs in Folder1 into PDFs.  I was going to have to play around a bit to understand clearly how that worked.

At the time when I closed this post, this process was still underway.  Additional steps I took were to run DoubleKiller for duplicative JPG filenames and then to do a directory listing of all JPGs on my drive.  To do that, in a CMD window, I went to the root folder (i.e., D:\ ) and typed this:  DIR *.jpg /a-d /s /b > JPG-List.txt.  That gave me a text file (JPG-List.txt) showing where all the JPGs were.  I put that into a spreadsheet and tested for duplicate output filenames.  Having already worked through duplicate filenames in DoubleKiller (by exporting the list of duplicates and generating batch-renaming commands in a spreadsheet), I did not find any duplicates now.  But I could tinker with filename extensions (e.g., .bmp, .jpg, .jpeg, .tif) and perhaps find that the same file existed under multiple names.  This was not exactly the same question as whether I had duplicates of the same photo; this was more a question of whether I had duplicate files under similar names.