CHKFILES Version 1.4
by Ron V. Webber
Release date: February 2, 1997 
http://www.lightlink.com/ym
Copyright 1997, Stochastic Systems

What is CHKFILES?

CHKFILES is a program that keeps track of the name, time, date, size, 
and checksum of every file in every path that you select (which could 
be every path on your hard drive).  You can select paths either 
recursively (where selecting "C:\" will select every path on partition 
C) or non-recursively (where selecting "C:\" will only select the root 
path of partition C).  On subsequent runs CHKFILES will update its 
information and tell you what has been added, changed, or deleted 
since the last run.  It will also tell you if any files have been 
corrupted.  If a file has a different time, date, or size, it will be 
listed as having been changed, and a new checksum will be calculated 
and stored.  For every file that has not changed time, date, or size, 
the current checksum will be calculated and compared with the old 
checksum.  If these are different, the file will be listed as bad.  
The old checksum on a bad file will be kept so that you can check the 
file again later once you have fixed it.

CHKFILES can store the information about every file in two different 
ways: The "One File" method stores all the information in one main 
file, named CHKFILES.ALL, which is stored in the same path as the 
CHKFILES program.  The "Every Path" method stores the information for 
each individual path in that path in a file named CHKFILES.CHK.  If 
you choose to use individual CHKFILES.CHK files for each path, the 
information remains valid even if you move it and all the files to 
another path, but you won't be able to tell if an entire path has been 
deleted since the CHKFILES.CHK file for that path would have been 
deleted as well.  If you choose to use one CHKFILES.ALL file, then you 
will be able to tell when paths have been deleted, but if all the 
files in a path are moved to a different path they won't be checked.  
(They would be listed twice: Once as having been deleted from their 
original path and once as being new files in their new path.) The 
"Every Path" method is good if you want to check files that are going 
to be moved to a new partition and you want to make sure they got 
there without any corruption.  The "One File" method is good if you 
want to have one file that you can copy to a safe location and use 
later to check on any corruption.  You can also use the "One File" 
method to check files on a device such as a CD-ROM.

The CHKFILES.CHK and CHKFILES.ALL files are in pure ASCII format, so 
you can print or edit them or use them for other purposes.  They also 
compress quite nicely, which is especially good if you want to store 
the CHKFILES.ALL file offline somewhere.

==========================================

Who can use CHKFILES?

CHKFILES is released as shareware and is licensed for individual use. 
Individuals may use CHKFILES for evaluation on their personal 
computers.  If they keep using it, they are expected to pay for it.  
(See the final section, "How do I pay for CHKFILES".)

Business, Commercial, Educational, Institutional, Corporate, or 
Government use of this version of CHKFILES is not allowed.  Contact 
Stochastic Systems if you wish to include a special version of 
CHKFILES with some commercial product. The only exception to this is 
that vendors of shareware programs may include the CHKFILES.EXE 
program and this text file as a shareware package being distributed.  
This means that you can include the CHKFILES package on a disk of 
other shareware that you are selling, but you can not use this 
version of CHKFILES as a file checking program to check for 
corruption in the files on the disk of shareware that you are 
selling.  If you received CHKFILES from a shareware distributor, it 
was NOT registered by that distributor and you are still expected to 
register if you continue to use it.

CHKFILES is distributed "AS-IS".  No warrantee is expressed or 
implied, including fitness for any purpose.  Stochastic Systems will 
not be responsible for any damage caused by the use, misuse, or abuse 
of CHKFILES.

==========================================

Why should I use CHKFILES?

Do you run your system with VERIFY turned OFF to save time?  When you 
do a tape backup, do you leave the auto-compare turned off?  If you 
answered yes to these questions, then you probably can't be bothered 
with a utility that, if your system is working 100% perfectly, may be 
just a waste of time.  BUT... if you would rather have some peace of 
mind, read on!

Situation 1a: You have a beautifully designed Summer Solstice Card on 
your computer that you use every year during that hurried summer 
holiday season. Sometime in August, after the holidays are over, this 
file is corrupted by that game you downloaded, tried once, and then 
erased.  Since you won't need Solstice Cards until next June, you 
don't notice the corruption.  You do your daily backups, your weekly 
backups, and your monthly backups.  Eventually, this corrupted file 
gets backed up to all of your tapes.  Next June, when you go to mail 
merge your database with your wonderful card, you notice the 
corruption.  You search all of your tapes and disks, and all you can 
find is the corrupted file.  Too bad you didn't have any way to know 
that it had been corrupted before you overwrote all your good backup 
copies!  If you had used CHKFILES at least once before the file had 
been corrupted, then the first time you used it after the file had 
been corrupted it would have warned you about it, in time to retrieve 
a good version from your backup tape.

Situation 1b: Instead of being corrupted, the file was somehow 
deleted. CHKFILES, by keeping track of what files are supposed to be 
in the directory, would tell you that the file had been deleted the 
next time you ran it.

Situation 2a: While you were away from your desk at work, your boss, 
needing to write a quick note, used your computer to type in and print 
out a message to the accountant about how wonderful your work was.  
The file is accidentally stored deep inside the directory that holds 
all of your fonts.  (You happened to be working on font editing 
before you were called away from your desk, and your boss couldn't be 
bothered to change directories before he saved the note.) Without 
CHKFILES, you never would have found this note.  With CHKFILES, you 
see that one of the new files on your computer is a text file inside 
the font directory.  That looks strange, so you look at the file and 
learn that now would be a great time to ask for a raise!

Situation 2b: Instead of being a file that you didn't expect to be 
there, it is a file that you wrote containing important client 
information, but you forgot where you stored it.  By using CHKFILES, 
you can get a list of all the new files on your computer and easily 
find what you need.

Situation 3:  You just downloaded a complex program that will install 
all sorts of files all over your system.  By running CHKFILES before 
and after installing this program, you can tell exactly what files 
this program added, changed, or deleted.  This information will be 
very useful when you want to remove this program from your system.

Situation 4:  Your brother-in-law is constantly messing with his 
computer and then calling you to fix it.  By running CHKFILES on his 
computer before he messes with it, you can then run it afterwards to 
see just what he has deleted so you can get him up and running much 
faster.

==========================================

How do I use CHKFILES?

CHKFILES.EXE is a self-contained program.  It is available in both a 
16-bit and 32-bit version, which are otherwise identical in operation.  
You can tell which version you have by the title of the opening 
screen.  The 16-bit version runs on Windows 3.1 or higher.  You can 
run the 16-bit version on Windows 95, but it only uses the short 
versions of file names.  The 32-bit version supports long file names 
in Windows 95.  It will also run in Windows 3.1 with Win32s 
installed.  There are no support files required.  CHKFILES will 
create a CHKFILES.PTH file in the same path as the executable file if 
you use the "Save Paths" option.  It will also store the CHKFILES.ALL 
file in the same path if you are using the "One File" option, or it 
will store a CHKFILES.CHK file in every path it checks if you use the 
"Every Path" option.  To run CHKFILES, either use the "Run" function 
in program manager, double-click on it from file manager or explorer, 
or assign it to a program group in program manager.  In Windows 95 
you can also put a shortcut to CHKFILES.EXE on your desktop or drag 
it to the start menu.

When CHKFILES runs, it first looks for a CHKFILES.PTH file in the same 
path. If it finds this file, it will attempt to open it and read the 
last paths and settings that were used.  If there is no CHKFILES.PTH 
file, which there won't be the first time you run CHKFILES, the 
program will come up with no paths selected and default to 
"Recursive" and "Every Path" modes.

If you want to save the paths that you select so that they will be 
there the next time you run CHKFILES, make sure that the "Save Paths" 
box is checked before you click on "Begin".  The "Save Paths" box is 
checked by default.

If you want to select every path on your C drive, select the C drive 
in the drive select box (upper left), click on the "<..>" entry in 
the directory select box until the root directory is displayed, and 
then click on the "Add Path" button.  An entry for "C:\" should 
appear in paths list box.  Make sure that the "Recursive" box is 
checked.

When you change drives in the drive select box, the directory box will 
be updated to show the subdirectories that are in the current path on 
that drive. The current path is shown at the top of the screen.  The 
"Add Path" button adds the current path to the path list box.  If the 
recursive box is checked, any path that is included inside another 
already selected path will be removed from the list box.  Duplicate 
paths are also removed.  Paths are shown sorted alphabetically.  This 
sorting includes all the characters in the path, including the final 
"\".

If you click on the recursive box when it is not checked, it will 
become checked and any now-redundant paths will be removed from the 
list box.  If you click on the recursive box when it is checked, it 
will become clear and all paths in the list box will be automatically 
expanded to show all paths inside of them.  This could take a few 
seconds if you have many paths on your hard drive(s).  You can click 
on the recursive box while it is expanding the lists and it will stop 
expanding and go back to the recursive path list.  This is useful if 
you have many paths on your hard drive and you clicked the recursive 
button by accident.  If you have too many paths on your hard drive, 
and the list box fills up, you will receive an error message saying 
that the list box is full.  This means that not all of the paths 
could be expanded.  If you click "Begin" with this incomplete list in 
the list box, not all of the paths will be checked.  (In tests with 
Windows 3.1, it required over 1000 nested directories to fill up the 
list box.  Windows 95 has an even higher limit.) If you click on the 
recursive box again, the list will be compressed back down. You can 
then click "Begin".  When you click "Begin" with the recursive box 
checked, the list of paths is expanded as they are being checked, and 
paths are removed from the list box once they are checked to make 
room as later paths are expanded.  This increases the number of paths 
that can be checked successfully.  If there are still too many paths 
to fit into the list box, you will get a message in the error box 
that will tell you which path was being expanded when the list box 
got full.  Checking will continue, but some paths may not be checked 
fully.  (A drive with over 2000 nested directories checked perfectly, 
so this limitation probably won't matter much.)

To remove a path from the path list, simply click on it.  Path delete 
is disabled while the path list is expanding through the use of the 
Recursive box.

If you want to quit from CHKFILES without checking any files, click 
the "Quit" button.  Any changes you made to the path list will be 
ignored.

Once you have all the paths set up the way you want them, click the 
"Begin" button.  If the "Save Paths" button is checked when you click 
on the "Begin" button, the paths and recursive state will be stored in 
the CHKFILES.PTH file located in the same path as the CHKFILES.EXE 
file.

If the "Recursive" box is checked when you click the "Begin" button, 
all the paths in the list box will be expanded to include all 
subdirectories.  Each subdirectory is expanded as it is being checked, 
so expansion doesn't delay the start of checking.

Before starting the actual file checking, the screen will be 
reconfigured to show five empty lists.  The caption of the window will 
show the name of the current path being checked.

The first list shows the new paths being checked and the new files in 
old paths.

The second list shows the names of all files deleted from old paths 
since CHKFILES was last run.  If you use the "One File" option, this 
list will also show any paths that were present the last time CHKFILES 
was run but are not currently present.

The third list shows the names of files that have changed since 
CHKFILES was last run.  If the line with the file name starts with 
"L!:", this means that the file has changed in length but not time or 
date.  If the file changed in time and/or date, the file name will be 
listed without any prefix.  (Normally, when a file changes the time 
changes as well.  It is somewhat unusual for a file to change in size 
without changing time or date, which is why this is flagged so you can 
know what is going on.)

The fourth list box shows the names of any files that are "bad".  A 
"bad" file is defined as one that has a changed checksum but not a 
changed time, date, or size.  "Bad" files will not be updated in the 
CHKFILES.CHK or CHKFILES.ALL file, so if a file shows up as "bad", the 
old checksum of the file will remain in the CHKFILES.CHK or 
CHKFILES.ALL file and not be updated to the checksum of the file as it 
now stands.  This is so you can restore this file from your backup 
(you DID keep a backup, didn't you?) and then re-run CHKFILES to make 
sure that your backup was good.  In the odd case where the file was 
changed intentionally somehow without changing the time, date, or 
size, and you don't want to do anything about it, then you will just 
have to ignore the "bad" reading.

The fifth list box shows any errors that happened during the running 
of the CHKFILES program.  This can include one of the other four list 
boxes running out of memory due to too many messages.  If the error 
list box ever runs out of memory due to too many error messages, you 
will be shown a message to that effect and then the checking procedure 
will abort.

During the check procedure, you can click on the "Abort" button.  This 
will abort the procedure after the current file is finished (which can 
take a few seconds if the current file is large).  The current path 
being worked on will not be updated.  If you are using the "Each Path" 
method, and the current path is a new one, then no CHKFILES.CHK file 
will be created in this path.  If the current path is an old one, then 
the CHKFILES.CHK file will not be updated. All previously checked 
paths will have been finished correctly.  If you are using the "One 
File" method, then the original CHKFILES.ALL file will remain intact.  
You can look through the results on the screen, but no information 
will be saved from this run.

When the last path is checked (or the abort button is pressed), the 
bottom of the screen will show some statistics, which will include the 
total number of files checked, the number of new files, number of 
deleted files, number of bad files, number of updated files, total 
number of bytes checked, time it took to check these files, number of 
bytes per second, and total number of paths checked.  Note that the 
total number of paths includes empty paths.  An empty path will not 
have a CHKFILES.CHK file put in it or will not be entered in the 
CHKFILES.ALL file.  If a path has only a CHKFILES.CHK file in it (all 
other files having been deleted) the files that the CHKFILES.CHK file 
says should be there will be listed as having been deleted and the 
CHKFILES.CHK file will be deleted, leaving an empty directory.  When 
using the "One File" method, a path that used to have some files in it 
that is now empty will have those files listed as being deleted but 
the now-empty directory will still be listed in the CHKFILES.ALL 
file.  Note that this is different from the case where the entire 
directory was deleted, which will only result in a single message 
saying that all the files in that directory were deleted rather than 
individual messages for each file.  If you then delete this now-empty 
directory and run CHKFILES again in "One File" mode, it will report 
that this directory has been deleted.  (If the directory never 
contained any files then it would never be stored and so deleting it 
would never be noticed.)

When the "Done" button appears, all checking is finished.  Clicking on 
the "Done" button will end the program.

CHKFILES was written to be very "multi-tasking friendly".  You can run 
CHKFILES in the background, minimized if you like, while you run other 
things. You shouldn't be changing, creating, or deleting files in the 
paths that CHKFILES is looking at, but you can certainly play 
Solitaire while checking your files.  Since CHKFILES is using the 
hard disk controller quite a bit, any program you use that accesses 
the hard disk will be slowed down somewhat and will also slow down 
CHKFILES.

==========================================

When should I use CHKFILES?

Any time you want to!  _I_ use CHKFILES at the following times:

 - Before a backup, so the backup will contain updated CHKFILES.CHK 
files, so I know if any files are bad or have been deleted so I can 
restore them before I do my backup, and so I can see if there are any 
new files that I don't need and want to delete so they don't waste 
space on my backup.

 - After defragmenting, so I know if any files were corrupted by the 
process. I always backup before defragmenting, and I always run 
CHKFILES before backing up, so I know that the files weren't corrupt 
before defragmenting.

 - After moving large blocks of files from one partition to another or 
to a new hard drive.  When I bought a larger hard drive, I ran 
CHKFILES (and backup), then copied all the files over to the new hard 
drive, and then ran CHKFILES again before deleting the old hard 
drive.

When do other people use CHKFILES:

One user downloads and tries out lots of shareware programs.  He uses 
CHKFILES to find out what files have been added to his system by these 
programs, which makes it easier for him to clean up his system.

If you find an interesting use, please let me know!

What do other people like best about CHKFILES:

One registered user had inadvertently deleted some important files 
from his system.  CHKFILES let him know that these files had been 
deleted, and he was able to restore them from his backup.

==========================================

Does CHKFILES work under Windows '95?

Certainly!  I use it all the time.  I would recommend the 32-bit 
version, as it recognizes long filenames, but even the 16-bit version 
will still check all the files properly.  (The 32-bit version also 
runs slightly faster.)

If you use CHKFILES to check all the paths in your WINDOWS directory, 
and use the "Each Path" option, you may notice that all the entries in 
your start menu have a CHKFILES.CHK file added to them.  This is 
because the start menu is stored in a directory structure which is 
normally filled with the links that point to the programs you want to 
run when you click on items in the start menu.  Since this is stored 
like any other directory structure, CHKFILES will check these link 
files and place a CHKFILES.CHK file in each path.  After running 
CHKFILES, the start menu will show these CHKFILES.CHK files in the 
menu.  If you want to remove these from the start menu you can simply 
set the CHKFILES.CHK files as Hidden.  There are many ways to do this: 
You can use the explorer, the "Advanced" editing in the "Start Menu 
Programs" section of the "Taskbar Properties", or the old file 
manager.  All you need to do is go into the subdirectories of the 
"Start Menu" directory (located in your Windows directory) and find 
all the CHKFILES.CHK files.  For each file select "properties" and 
then click on the "Hidden" box and then click on "Apply". Hiding the 
CHKFILES.CHK file will only stop it from showing up in the Start menu, 
and maybe in the explorer.  It won't stop it from being found by 
CHKFILES and used to check the status of the other files in the 
directory. Starting with version 1.3, CHKFILES now can find a hidden 
CHKFILES.CHK file. The file will remain hidden even when it has been 
updated so you won't have to go back and hide it again.  If you remove 
all the other items from the directory then the CHKFILES.CHK file will 
be deleted the next time CHKFILES is run.  If you then add files back 
to that directory, a new CHKFILES.CHK file will be created which will 
not be hidden, so you will need to hide it again.

If you have any program shortcuts on your desktop, you will find that 
CHKFILES will create a CHKFILES.CHK file on the desktop when run in 
"Every Path" mode. This is because all the shortcuts are stored in a 
directory called "Desktop", and CHKFILES checks this directory just 
like all the others.  The easiest solution, if you want to continue 
running in "Every Path" mode, is to simply delete this CHKFILES.CHK 
file from your desktop after you run CHKFILES.  You can easily drag 
this file to the Recycle Bin.  Marking this file as "Hidden" doesn't 
seem to make it disappear from the desktop.  You could also run in 
"One File" mode.

==========================================

Can I run both the 16-bit and 32-bit versions on the same computer?

Yes, but remember that the 16-bit version doesn't recognize the long 
versions of file names, so if you are using Windows 95 and alternate 
between the two versions you may see the 16-bit version reporting all 
your files with long names as being deleted and the short name 
versions of these files listed as new.  Then when you run the 32-bit 
version, it will report that the short name versions have been 
deleted and the long name versions will be listed as new. This 
happens in "Every Path" mode because both versions use the same 
CHKFILES.CHK files for their information.  If you use "One File" 
mode, it would be better to put the two versions in separate paths so 
that they would use their own versions of the CHKFILES.ALL file.  If 
you keep both programs in the same path, they would not only cause 
false deleted/new reports on files, but also on whole paths that 
contained at least one long name.

==========================================

Can I run in both "One File" and "Every Path" mode on the same 
computer?

Yes.  The two modes don't interfere with one another, though you will 
see listings for new and changed CHKFILES.CHK files in every path when 
you run in "One File" mode, and you will see listings for a new or 
changed CHKFILES.ALL file when you run in "Every Path" mode.  When 
CHKFILES runs in "One File" mode, it ignores the files CHKFILES.ALL 
and CHKFILES.TMP in the path where it is running from.  (If you have 
files with these names in other paths it will process them just like 
any other file.)  It will also process any CHKFILES.CHK files in any 
path just like any other file.  When CHKFILES runs in "Every Path" 
mode, it ignores any file named CHKFILES.CHK in any path, since that 
is where it stores its information, but it doesn't ignore the 
CHKFILES.ALL or CHKFILES.TMP files.  Note that the CHKFILES.TMP file 
will normally only exist while CHKFILES is running in "One File" 
mode.  It automatically deletes this temporary file when it is done 
running.  If your system crashes during a run, this file may still 
exist, but it will be deleted the next time you run CHKFILES in "One 
File" mode.

==========================================

Why did I write CHKFILES?

Because I wanted a program that would do this sort of thing and I 
couldn't find one.  There may be some other program out there that 
does the exact same thing, but I don't know of one that works in 
exactly the same way.  I also wanted something fairly easy to write 
that I could use to try out the shareware market.

A well-known anti-virus program from a well-known software company 
does something like CHKFILES - it creates a small file in every path 
with checksums in it - but it didn't do this in the way I wanted it 
to, wouldn't give me the information I wanted, and I couldn't get it 
to do only the paths I wanted.  It also seemed to only calculate 
checksums on executable files, and I wanted to check all the files.  
(It uses the checksums to see if an executable file has been modified 
by a virus.  I wanted to use checksums to see if files had been 
corrupted.)

Many years ago I attended a talk by a programmer who was describing 
his new backup program.  It was called the "GOOD" backup program, and 
he made a strong case about always doing a checksum of every file and 
checking each file before storing it to the backup.  He used the story 
of a corrupt file that was used only once a year not being discovered 
until it had been copied to all the backup disks, thus making recovery 
impossibly.  I bought a copy of his program, used it religiously, and 
was very glad every time it enabled me to find a corrupt file and 
recover from it.  This was for a different computer system, and the 
"GOOD" backup program was not a big seller, but it made a big 
impression on me.

When I started using Windows, I wanted the same sort of protection, 
but I couldn't find it.  I toyed with the idea of writing my own 
version of "GOOD", but since tape backup was so much more convenient, 
I decided to write CHKFILES to add the protection I wanted without 
having to rewrite the entire backup program.

The first version was done in Visual Basic version 3.  It worked, but 
it was slow doing the checksums on the files and had some problems 
with certain "unusual" date combinations.

I then moved the checksum routine to a DLL written in Turbo C++ 3.1, 
and that sped things up quite a bit.  (The checksum routine is now so 
fast on a modern computer that the slow part is reading the file off 
of the hard drive.  I was thinking of optimizing the checksum routine 
in assembly language, but that wouldn't make much difference.)

When I thought about releasing CHKFILES as shareware, I wanted it to 
be a self-contained executable without requiring any external DLL's.  
For this reason I translated it into Turbo C++.  (I also wanted to 
have a project so I could learn Windows programming in C++.) I then 
updated to Borland C++ version 4.0, which allows the program to 
easily release time to other tasks when it is busy doing something 
complicated.  This allowed me to play Freecell while the files were 
being checked.

The concept and basic structure of CHKFILES seems very solid.  I have 
been using it on multiple machines for over 4 years now.  The C++ 
version also seems very solid, though there are a few areas that are 
not fully "idiot-proof".  See the next section.

==========================================

How dangerous is CHKFILES:

I have taken many precautions to avoid potentially dangerous 
situations.  If you are using the "Every Path" mode and a path already 
contains a file named CHKFILES.CHK, but it is not a file that was 
created by this program - say for some strange reason you saved your 
favorite apple pie recipe in a file of this name - you will get an 
error message that this path can't be processed and your pie recipe 
will not be touched.  (If your pie recipe file happens to be in the 
same format as a CHKFILES.CHK is supposed to be in, then it will get 
modified.)

When using the "One File" mode, CHKFILES uses a temporary file called 
"CHKFILES.TMP" and creates or overwrites a file called "CHKFILES.ALL".  
When you save paths, it creates or overwrites a file called 
"CHKFILES.PTH".  It does not check to see if these files may actually 
contain something you want to keep, but it only does this in the path 
that the CHKFILES.EXE program is running in, so you are pretty safe.  
If you must use files with these names, put the CHKFILES.EXE program 
in a different path.

If your hard drive is so full that it doesn't have room for the 
CHKFILES.CHK or CHKFILES.ALL files, the program may crash, but it 
shouldn't do any damage (other than filling up what little space you 
had left).

When using the "Every Path" option, the contents of the CHKFILES.CHK 
file that is being created or updated is kept in memory until the 
entire path is finished, and then the file is created and re-written.  
If the system crashes during the path checking, the old CHKFILES.CHK 
file will remain intact.  If the system crashes during the short time 
that the CHKFILES.CHK file is being written, it is possible that a 
corrupt or incomplete CHKFILES.CHK file will be in the path.  In this 
case, this path may give an error message the next time you try to 
check it.  The corrupt CHKFILES.CHK file will not be deleted 
automatically, because the program doesn't know if this corrupt file 
is really a corrupt file or your pie recipe.  You would then have to 
manually delete this corrupt file and recheck that path.

When using the "One File" option, the contents of the CHKFILES.ALL 
file that is being created is stored as CHKFILES.TMP.  This is 
because the old CHKFILES.ALL file is read as each path is checked.  
If the system crashes during checking, the old CHKFILES.ALL file will 
remain intact and the CHKFILES.TMP file may remain in the path.  The 
CHKFILES.TMP file will be overwritten when CHKFILES is next run.  
When the checking is done, the old CHKFILES.ALL file is deleted and 
the CHKFILES.TMP file is renamed to CHKFILES.ALL.  It is unlikely 
that any corruption of the CHKFILES.ALL file could happen.

There are limitations on the number of paths that you can check in one 
run of CHKFILES.  The paths are stored in a standard Windows list box, 
and these list boxes can't hold more than 32K of text.  Assuming 32 
characters in the average path, this means you couldn't check more 
than 1000 paths in one run.  You could, however, run CHKFILES 
multiple times with different sets of paths. Only one user has ever 
reported hitting this limit, and he was using an older version of 
CHKFILES.  With version 1.3, the paths are expanded while they are 
being checked, and paths that have been checked are removed from the 
list to free up space.  If you had all 1000 subdirectories in the 
same directory, you would still have this limit.  If you had these 
directories nested within one another (a more likely situation) then 
you probably wouldn't hit this limit. Also note that Windows 95 
expands the memory limit on list boxes so you probably won't see any 
limitations when running CHKFILES under Windows 95.

Because of the same listbox limitation, if you have too many new, 
changed, deleted, or bad files, the list boxes may overflow during 
checking.  (This is one reason when an entire path is new it only 
generates one line saying "All files in path X" rather than a line for 
each new file.) If, for example, you have thousands of picture files 
in multiple directories that have already been checked, and then you 
run all of these picture files through a program that creates 
thumbnail files for each picture, you could end up with so many new 
files in old paths that the "new files" list box would fill up.  This 
_has_ happened to me, before I switched to Windows 95.  In this case, 
the list box that filled up would stop accepting any more information 
and an error message would be added to the error list box stating 
that the "new files" list box was full (or whatever box happened to 
fill up).  Once this error message is added to the error list box, no 
more attempts are made to add information to the full list box, so 
you won't get multiple error messages about the same problem.  
Checking will continue so that all the selected paths will be 
checked, and all you will lose is the notification about more files 
of the type that caused the list box to fill up.

==========================================

What should I not bother complaining about:

CHKFILES was designed to be a self-contained executable.  As such, it 
doesn't use or need any external files (except the CHKFILES.PTH file 
to store the paths and the one CHKFILES.ALL file or the multiple 
CHKFILES.CHK files, but it creates these for you).  Because of this 
goal, CHKFILES does not use any of the currently fashionable "3D" 
buttons or other fancy stuff.  This is not because I couldn't figure 
out how to use such things.  Borland makes it very easy to use fancy 
looking controls, in fact it takes a little more work to get a plain 
dialog without the fancy features!  If there is enough demand for it 
(from paying customers) I could easily add such things.

CHKFILES was designed to be easy for ME to use.  I use a mouse to run 
it.  I realize that someone who tries to use the keyboard will have a 
very hard time of it.  Specifically, with the keyboard it is not 
possible to select individual items in the directory and paths list 
boxes.  Since I didn't want to have to double-click on items with the 
mouse to select them, that meant that keyboard use would be 
restricted.  Sorry.  (The earlier version in Visual Basic required 
double clicking, and I didn't like that.)  Windows is hard enough to 
use with just a keyboard that I figure that not enough people will 
need to use the keyboard to make it worth while.  If this causes 
anyone real problems, please let me know.  I have some ideas on what 
to do about this, but if no one needs it, I won't bother with it.

==========================================

What is in the future for CHKFILES:

CHKFILES is shareware.  This was my first venture into Windows-based 
shareware, though I have a different shareware program on another 
platform and have actually received some payments for it (though not 
that many).  (This other program, Rapsheet, is now available in 
Windows.)  I am not expecting to get rich from this program, but if I 
make enough I will keep supporting it and do some other programs.

There are some enhancements that I plan on adding to CHKFILES, and I 
will continue to fix bugs or limitations as they come up.  How much 
work I put into upgrades will depend on the response I get.  Some of 
the plans I have include adding things that happen when you click on 
files after the checksum phase is over (or possibly during it).  For 
instance, if you clicked on a file marked "Bad" you could get the 
option of marking the file as good and updating the CHKFILES.CHK or 
CHKFILES.ALL file.  If you got an error saying that a CHKFILES.CHK 
file was corrupted so it couldn't process a path, you would get an 
option to delete the CHKFILES.CHK file and reprocess that path.  If 
you got an error due to an overflowing list box, it could pause for 
you to read all the list boxes and then clear their contents and 
continue.  So far, none of these things have been requested by 
registered users.  The features I have added have mainly been ones 
that users have requested.  If you have other things you would like, 
let me know.

==========================================

Can I use CHKFILES commercially or in an educational or governmental 
institution?

The shareware release of CHKFILES is only for individual use.  If you 
wish to license a special version of CHKFILES for your business or 
other institution, contact me at the address given below.  The 
commercial licensing rate is quite reasonable, and there are quantity 
discounts.  The special version would have your business or 
institution name clearly visible to the user.

==========================================

How do I pay for CHKFILES:

If you like CHKFILES, use it and share it with your friends.  If you 
find that you use it regularly, I would expect you to register it.  
The recommended registration fee is US$10.  If you are from outside 
the U.S., please make sure that your monetary instruments are easily 
cashable in the U.S..  Foreign currency is acceptable.  Since CHKFILES 
is fully functional as it stands, there is no registration "key" that 
you need back from me.  (Sorry, the initial startup screen can't be 
disabled.) Maybe in the future, if there is an installed base of 
registered users out there, I will add some features that can only be 
activated by a key.  If this happens, I will contact you with your key 
and where you can get a copy of the updated file.  Because of this 
possibility, please send me some way to contact you (email preferred) 
and also let me know where you got your copy of CHKFILES so I know the 
best way to release updates so you can receive them.

If you like CHKFILES, but think you will wait for some specific new 
feature until you register, you may be in for a long wait.  The 
Windows 95 version that uses long file names is only now being 
released, thanks to user support.

If you use CHKFILES and don't pay for it, and then later it saves you 
from losing something important, I would expect you to pay for it.

If you use CHKFILES and don't pay for it, and you find that it gives 
you pleasure and peace of mind every time CHKFILES tells you that all 
your files are safe after you do something like copy them over or 
defrag your hard drive, then I would expect that after a while that 
peace of mind would be worth paying for.

If you use CHKFILES and give it to your friends and brag about what a 
wonderful program it is, I would expect you to pay for it.  Then you 
could brag about what a wonderful person you are because you paid for 
what you used, and you could shame all of your friends into doing the 
same thing!

If you have never experienced that warm fuzzy feeling that comes from 
knowing that you have done a good thing, I would recommend that you 
pay for CHKFILES. It's cheap, as far as shareware goes, and if you 
get that fuzzy feeling then you can get it again by registering other 
shareware you use!  (If you don't get that fuzzy feeling, or don't 
like it, then you won't be out as much as you would be if you had 
registered a more expensive program!)

You may mail your money to:

Ron V. Webber
Stochastic Systems
P.O. Box 925
Dryden, NY 13053 USA

Make your checks or money orders payable to "Stochastic Systems".  If 
you are from outside the U.S., you can send cash in your local 
currency.

I can be reached by email at:  ym@lightlink.com

You can also reach me at my web page:  http://www.lightlink.com/ym

The web page has a link to the latest version of CHKFILES and also has 
links to any other shareware programs I may have released.

I am interested in knowing who is using CHKFILES.  If you find an 
interesting use that I didn't think of, let me know by email.  If you 
have sent me money, let me know that it is on the way.  If you find a 
bug or could recommend a new feature, let me know.  If you think it is 
stupid and a waste of your time, don't bother to let me know.

I would also be interested in hearing ideas for more projects, job 
offers, donations, praise, etc..  Sorry, marriage proposals will no 
longer be accepted.  (My wife wouldn't like that!)

==========================================

Revision history:

Version 1.4 finally fixed the last (?) incompatibility with Win32, and 
is the first release to have both 16-bit and 32-bit versions.  (The 
last problem was the way Win32 stored volume names, which is quite 
different from the way 16-bit Windows does it.)

The "<..>" entry was removed from the directory list for root 
directories. This would only show up on networked drives that look 
like root directories but are actually subdirectories on other 
computers.

The "One File" option was added to store all information in a master 
file called CHKFILES.ALL.  This was requested by some users.

The main screen now shows the copyright notice, which was previously 
only on the startup screen.  This is needed for commercially licensed 
versions that do not have the startup screen.

The CHKFILES icon on the main screen now brings up licensing 
information.

Version 1.3a corrected a bug that was reported by a user.  If you have 
a subdirectory whose first character is one of the following 
non-alphanumeric characters: !"#$%&'()+,- then when the recursive 
search would lock up, which could cause a general protection fault.  
The reason for this is that the program always assumes that the first 
entry in the subdirectory list is the ".." sequence, which marks the 
way back up the directory tree.  Since the subdirectory list is a 
sorted list and the characters given above come before the "." 
character in the normal character set, this would stop the ".." entry 
from being the first one in the list.  The solution was to change the 
first entry from "[..]" to "<..>".  Since the "<" character comes 
before "[" in the character set, "<..>" would always sort to before 
"[anything]", which solves the problem.

Version 1.3 Changes:

Changed the way information was stored internally, resulting in a 
slightly smaller program than 1.2, even with more features!  The most 
visible change is that the path expansion when you click "Begin" is 
now done during the checking phase.  Previously, when you clicked 
"Begin", all the paths would expand first, and then the checking 
phase would start.  This caused a delay before checking started and 
meant that you couldn't check more paths than would fit into a list 
box.  By expanding paths as they are checked and removing checked 
paths from the list box, many more paths can be checked.  (If you 
have two directories, each with 500 subdirectories in them, the older 
version might not be able to fit all 1000 paths into the list box.  
Version 1.3 will expand the first 500 subdirectories, check and 
remove each of them from the list box, and then have plenty of room 
to expand the second set of directories.  Expanding paths by clicking 
on the "Recursive" box will still have the original limitation, but 
it now has an error message telling you that not all paths could be 
expanded and that you should click the "Recursive" box again to 
compress the paths before clicking "Begin" to start checking.

Each path now ends in a final backslash.  Before, only root 
directories ("C:\") would have the final backslash.  This 
modification allows the paths to be sorted better and aids in the 
proper collapse of expanded path lists.  The CHKFILES.PTH file still 
stores the paths without the final backslash, except for root 
directories, in order to maintain compatibility with older versions.

Files which have a date after 2079 will now have their dates stored 
using the full four digits.  Previously, only the last two digits of 
the date would be stored in the CHKFILES.CHK file - 80 to 99 
representing 1980 through 1999 and 0 to 79 representing 2000 through 
2079.  It is possible to set the date on the computer as high as 2099, 
and if you had any file with such a date on it the program would 
always report that the file had changed.  For example, a file that 
thought it was created in 2083 would previously have the date 
recorded as "83", which would be confused with 1983.

If the CHKFILES.CHK file is marked "Hidden", it will still be found 
and updated while remaining hidden.  Previously, if the CHKFILES.CHK 
file was hidden, the program would not find it and would treat the 
path as a new one, though when it tried to create a new CHKFILES.CHK 
file in the path is would overwrite the hidden one and the new file 
would retain the hidden attribute of the older file, thus the 
CHKFILES.CHK file would remain hidden but the files would not be 
checked and the path would constantly be listed as new. This feature 
was added because of the way Windows '95 stores the task bar start 
menu.  The menu is stored as a nested directory structure  in the 
"Start Menu" directory (usually STARTM~1 in short file names).  Any 
files found inside this "Start Menu" directory will be shown in the 
start menu, and this includes the CHKFILES.CHK files.  Since you 
wouldn't normally want to see the CHKFILES.CHK files in your start 
menu, you can now make these files hidden (using the Explorer or File 
Manager) so that they won't show up on the start menu but will 
continue to protect the files in the start menu.

Version 1.2 changed how some of the internal disk routines worked, 
trying to eliminate any that don't work with Win32.  This is in 
preparation for a 32-bit version that will handle the long file names 
of 95 and NT.  This version also will recognize subdirectories and 
files that are marked "System" (but not those marked "Hidden"), which 
the previous versions would ignore.  Note that this still doesn't work 
with long file names since it is still a 16-bit application.  If I 
compile it as a 32-bit application, which I have done in unreleased 
tests, it works with long file names, but some other things don't work 
properly.

Version 1.1 translated characters from DOS text to Windows ANSI text.  
This would only show up on files with non-standard characters such as 
the one-half symbol. 

Version 1.0a corrected a minor bug that would cause the first 
subdirectory on any given partition to be skipped if you operated in 
Recursive mode.

Version 1.0 was released for about 2 hours and no one ever used it.

 

==========================================

Other products from Stochastic Systems:

RapSheet Time Logger.  Helps you to keep track of how much time you 
spend doing various tasks.  It can be used to determine a breakdown of 
your time spent doing various types of things on your computer, which 
is useful (and required) for those who plan on deducting some of their 
computer expense from their taxes.  It can also be used to keep track 
of any other time based activities.  Available NOW from the Stochastic 
Systems home page and from major shareware distributors.

Coming Soon (maybe): The Too Many Notes Tune Editor.  At the forefront
of CAMP (Computer Aided Music Performance).  Allows you to create
musical performances that sound exactly the way you would have played
them if you had the talent to play them that way.  Requires the
ability to read music and a sense of rhythm, but not necessarily at
the same time (or by the same person). 
