Validate or Check?

Discussion in 'NIS File Check Forum' started by bellgamin, Aug 7, 2002.

Thread Status:
Not open for further replies.
  1. bellgamin

    bellgamin Very Frequent Poster

    Joined:
    Aug 1, 2002
    Posts:
    5,648
    Location:
    Hawaii
    Please... what is the difference between "Check all records" & "Validate all records" ??

    Arigato,
    Bell
     
  2. jvmorris

    jvmorris Registered Member

    Joined:
    Feb 9, 2002
    Posts:
    618
    My apologies. I started to frame a reply earlier this morning, but had to leave.
    First, I assume you've read through the FAQ in the other Forum that FanJ has been publishing? If not, you should do that first in order to understand what I'm going to say (rather briefly) below.

    First, as noted in the FAQ, it's absolutely essential to set up a baseline on your system. Actually, this is a two-part process. First, you have to run NFC for the first time and then you have to validate the initial dataset. (The second part isn't so easy because you really have no definitive method of guaranteeing that all the files in the initial baseline are authentic.) It seems, from your other post that you've done this, however.

    Now, after the baseline is established, you run "Check all records" on a more or less regular schedule to ensure that none of the files have mysteriously changed. You can either do this manually when and as you choose using the method that Albert describes in his Help file or you can do what I do -- schedule the check using Task Scheduler. I do this on a daily basis. If you use Task Scheduler and there are no changes, then the program will provide a "Success" flag and exit without even bothering you. (Furthermore, you can confirm that it has, in fact, run by checking the Task Scheduler log.) However, if anything about the targeted executables has changed, then NFC will open a window on your desktop with the changed, deleted, missing, new or 'moved' files highlighted in red (at least they're in red on my box).

    You now have to personally 'validate' each and every one of the changed executables as being legitimate. The program cannot do this for you (nor will it ever be able to.

    I'm assuming that the concept of 'deleted, missing' or 'new' files is self-evident. But what's a changed file or a moved file (or a renamed executable, for that matter)?

    Well, a changed file is a file in which the "Check" operation finds a different file size, file date (last modified), or file hash (checksum, if you prefer). In any of these instances, something has definitely happened since the prior run. Now, the program can't determine if that's legitimate or not; you have to make that determination yourself. If you've updated the file, well then, sure, some (and probably all) of these parameters are going to be different. In this instance, the Validate | Validate current record choice would be appropriate. Select the highlighted row and do it.

    Well, what if you see a file changed that you simply can't rationalize as being the result of a product update? In that case, the best thing to do is to ask -- and this is a good place to do it, right here, this forum. Now, what if you can't find a valid reason for how the file could have been changed? Probably a good idea to do a 'roll-back' to the prior copy of the executable. If it's a Windows system executable, you can do that using SFC in Win 98 (the utility is a bit differently named in subsequent Windows OSs, unfortunately). If it's something other than a Windows system file, you're probably best advised to do a roll-back to the CD or download from which it was installed initially and then do updates from the vendor's website that may be available.

    Tip on downloaded applications and application updates Set up a downloads directory somewhere off the root of a drive that you select. Create a folder for each vendor whose products you use. Within the vendor folder, create a sub-folder for each product. When you do a web-based download, download and 'save to file' the download in the product directory for the relevant vendor. (Some vendors tend to be a bit clueless and use the same download file name for different versions of their applications or updates or upgrades -- don't you make that mistake -- rename the downloaded file if necessary with a version or update number as appropriate to differentiate it from previously downloaded files relevant to the application in question. Don't overwrite a previous download unless you have good reason to believe it was corrupted in the download process. Get offline, run NFC before doing the install. (And clean up anything unexpected before you proceed.) Now do the install. This may involve running a self-installing executable or unZIPping a ZIP file into a target directory (not the downloads folder!). Then run NFC again, and verify all the new, added, and deleted executables that result.) You may unexpectedly find several executables that you weren't expecting. Those may be well worth more attention on your part. (Especially, this is likely to suggest an AdWare product and a utility like Ad-Aware can come in very handy at this point. Not all adware products are up-front about what they're going to install on your box.) This procedure gives you a permanent copy of all of your web-based downloads and facilititates a roll-back, should this become necessary.

    Moving on, a 'moved' file (or application) is going to show up as being highlighted as 'deleted, missing' from its original directory and 'new' in its new directory. This gets a bit tedious, so it's definitely best to handle the 'changed' files first. And, of course, the situation is quite similar if you simply 'rename' an executable or application in its existing directory -- you'll see the 'old' file as missing and the 'new' file as added.

    The only practical means to do this is to run NFC fairly regularly (like daily or immediately before and after a deliberate download and install). If you put this off and only do it weekly or monthly (or irregularly) you probably won't have the foggiest idea as to whether the changed executable is a result of an application upgrade, fix, or patch when you find it -- that is, when NFC highlights the change.

    What you are looking for is new, modified, deleted, re-named, or moved files that you can't explain; this suggests either corruption or subversion of the executable.

    Now (finally) with regards to Validate | Validate all records..., I personally use this choice only rarely. If I am absolutely, positively, irrevocably convinced that every modified, missing, moved, new, or renamed file is the direct consequence of an application update, then yes -- I may use that option to validate any changed information. (In other words, I use it rarely; I use the Validate | Validate Current Record option normally.)

    (I need to go back and re-read the above, just to ensure that it makes sense.)

    Well, one other note may be appropriate. I don't download executables helter-skelter anymore. Indeed, it's fairly unusual for me to install a new app or update an existing one. Similarly, it's very rare that I uninstall a previously installed application. Consequently, I don't have to contend with NFC 'change' notifications on a frequent basis. However, if you do frequently download and install new apps, delete apps, or re-organize/re-name app directories, then you're going to be sort of busy while using NFC.

    Hope this helps.
     
  3. bellgamin

    bellgamin Very Frequent Poster

    Joined:
    Aug 1, 2002
    Posts:
    5,648
    Location:
    Hawaii
    Superb!

    I have software that I paid LOTS of $$$ for, but I don't get support that even comes close to what you just gave me for free!

    Thanks. I mean REALLY thanks.

    Shalom, Bellgamin
     
  4. jvmorris

    jvmorris Registered Member

    Joined:
    Feb 9, 2002
    Posts:
    618
    Well, which is it? Arigato or Shalom? :D (You're trying to drive me nuts, aren't you -- gonna make me look up your profile :rolleyes: )
     
  5. bellgamin

    bellgamin Very Frequent Poster

    Joined:
    Aug 1, 2002
    Posts:
    5,648
    Location:
    Hawaii
    My spouse's native tongue is Nihon-go. Hebrew comes by virtue of extensive Bible study/teaching. On the other hand...

    Mahalo nui loa,
    Bellgamin
     
Thread Status:
Not open for further replies.