Sanity Checker  Sanity Checker

go to home page Student Projects full screen, hide local find menu Google search web for more information on this topic jump to foot of page translate this page with Babelfish ©1996-2009 Roedy Green, Canadian Mind Products
This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project.

This project outline is not like the artificial tidy problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project, and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project in any way you please and to keep all the profits from your endeavor.

Please do not email me about this project without reading the disclaimer above.

This program has two uses:

  1. Checking that all files e.g. EXEs and DLLs needed by an OS or application are present and intact.
  2. Replacing defective or missing files to restore a system to sanity.
It is table driven. You need a table with entries like this:
Field Purpose
filename The name of the file to be checked.
timestamp The date and time the file should be stamped.
size The size the file is supposed to be in bytes.
checksum The 32-bit Adlerian checksum of the file. This can be used to detect corruption. If the computed checksum for the customer’s file does not match this, it means it is corrupt, possibly virus infected.
source Where to get a copy of this file if it is missing or corrupt. Possible sources include:
  • LAN : from another machine on the network.
  • SNAP : from a snapshot taken when the OS or application appeared to be functioning properly.
  • CD : from the master CD, possibly zipped, compressed, CABed or otherwise archived.
  • DOWNLOAD : from a downloadable installable EXE, stored either locally or on the vendor’s site. Ideally you can automatically fish out the files you need from the install executable without totally reinstalling the entire app.
  • CENTRAL : from a central repository on the web. There are legal ramifications here.
  • REINSTALL : Ask the user to reinstall some app or device driver to get the needed files, then redo the sanity check.
  • MANUAL : it is up to the user to find a replacement copy, perhaps by asking a friend to email a copy.
needs What other files must be present if this file is present.
needed by When any of these files are present, this file must be present. REQUIRED means the file must always be present, irrespective of what other files are present.
Ideally the manufacturer of the OS or the application would provide a script giving this information that is fed to a standard engine that checks for sanity and repairs any damage it finds. This technique does not detect or correct datafile corruption, but it can detect and correct various DLL hell problems. Ideally there would be a way to specify custom sanity checkers for various datafiles, and possibly program that attempt to clean out damage in datafiles. The general engine can also detect and correct damage done by viruses or virus infection. The technique does not depend on recognising the virus, so it works even on new viruses.

If the app could not be repaired, it would be removed entirely including registry entries.

There are four main difficulties to solve:

  1. To replace a DLL, you must use a special mechanism that swaps it at the next reboot. You can’t replace them on the fly.
  2. You might sneak by legal problems of holding proprietary code on a central website by never letting users or your utility download it. Instead you download only the differences needed to correct the damaged version. This requires uploading the damaged version. This goofiness makes the process take twice as long, and won’t handle the problem of a file missing entirely.
  3. Extracting replacement files from master CDs or downloadables could be quite an exercise when you consider all the different non-standard ways of archiving files.
  4. Building the scripts. You need to know quite a bit about the app and the various ways it can be installed to generate the needs and needed-by data. Collecting such trivia would be exceedingly boring. You would need to create separate scripts for every fixpack level of every OS and every app. You might only attempt to support the latest and greatest. You generate your scripts entirely by taking a snapshot of the customer’s machine when it is in a working state. However, few customers would be interested in the product until their systems were already corrupted, too late to take a snapshot.
This project could be thought of as a specific implementation of the Automatic File Updater. You could think of sanity restoration as a type of incremental install. You declare that version 10 of the program should be installed, and let the sanity checker do whatever is necessary to convert version 9, a damaged version 9, nothing or whatever is there, into version 10, downloading the bare minimum to do it.

You might look at the Jardiff protocol in Java Web start for fetching just parts of jars you need, or the Replicator which delivers bundles of compressed files. The server might deliver bundles of compressed files, individual files, or archives composed on the fly of just what the client needs, taking the pieces from pre-compressed files.

Automatic File Updater
installer
JVM manager
CMP homejump to top You can get the freshest copy of this page from: or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
http://mindprod.com/project/sanitychecker.html J:\mindprod\project\sanitychecker.html
CMP logofeedback Please email your feedback for publication, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : feedback email
mindprod.com IP:[65.110.21.43]
view BlogYour face IP:[38.107.191.106]
You are visitor number 5,347.