Sanity Checker

This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. It does not describe an actual complete program. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; I have too many other projects of my own.

I do contract work for a living, which could include writing a program such as this. However, 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 any way you please.

This program has two uses:

Checking that all files e.g. EXEs and DLLs needed by an OS or application are present and intact.
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.

There are four main difficulties to solve:

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.
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.
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.
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 projectcould 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

	Please email your feedback for publication, errors, omissions, broken/redirected link reports and suggestions to improve this page to Roedy Green :
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
	Your face IP:[38.103.63.16]	The information on this page is for non-military use only.
	You are visitor number 3,443.	Military use includes use by defence contractors.
	You can get a fresh copy of this page from:	or possibly from your local J: drive (Java virtual drive/Mindprod website mirror)
	http://mindprod.com/project/sanitychecker.html	J:\mindprod\project\sanitychecker.html