BackEmUp

Purpose

BackEmUp is a simple, non graphical user interface incremental file backup program. (A prototype gui - BackEmUI - has been released as a Beta development. This PM interface calls the command line code to perform the actions.)   It is able to backup an entire drive, or only certain subdirectories, or utilitze a user specified list of files/directories (specification mask) to exclude certain entities or only include certain entities. Hidden and System files as well as Extended Attributes are backed up. It can maintain multiple versions (generations) of a file. It can back up to any random access device: floppy disks, zip drive, another hard file, or a lan drive. Presently, it can not back up to sequential tape devices. It can use CD-R and CD-RW media for certain features. It has been tested on OS/2 Warp 4, Warp Server for e-Business, and Windows 95/98. Files backed up under one operating system may be restored to another. It uses a simple plain text ASCII control file that is easily viewable or editable with standard text editors (be sure to save it as plain text if you do edit it ... do not save it as a Rich Text or MS Word document!)

User exits can be optionally utilized to compress (zip) the data files as they are being backed up, or to encipher the backup for security.

Enabling the compress option may effectively increase the amount of data that can be backed up to each removeable media disk. Files that are larger than the backup media are automatically split into smaller pieces during backup, and rejoined during restore.

Mixed backup media types (such as R/W disks combined with CD-R) can be employed using the concept of inactive volumes.

Dislaimer and License

There is no expressed warranty with this product. You, the user, assume all risk and responsibility for any damage or data loss to your system. I will not be liable for anything as the result of your use of this product. This product may not perform as claimed in this document. If you do not agree that the author has no liability, nor that no guarantee is implied with this product, you are hereby forbidden from attempting to use it on any machine in any method, and must immediately delete it from your system. Use is strictly "as-is" and you assume all risks.

Change history

Versions 1.0 to 1.4 used privately since the late 80's.

Version 1.5 - Jan 2, 2002: initial public distribution

Version 1.7 - Jun 30, 2002: Enhance calculations estimating the size of a backup volume that may eventually be placed on a CD. Account for differences in CD allocation unit size versus a backup directory on a hard file. Reference description of MAX_VOL_SIZE and TARGET_MEDIA_ALLOC_UNIT options.

Version 1.8 - Aug 31, 2005: Large (>2 gig) file support,
    -  fix bug with restore under mask from a zip archive,
    -  add "/trickle" and "/drop" options.

Version 1.8 (Beta 3) - January 6, 2006: Fix bug with /dtllist report.
    -  allow zero byte files to be restored
    -  consider available temporary space when chunking files

Version 1.8 (Beta 4) - December 8, 2006: Fix bug detecting full disks in Automatic volume creation mode (RMA)
    -  minor tweaks to "stdout" logging output for the 'backup' function
    -  Fixed bug with restore and files excluded but present on the backup media
    -  Fixed bug GUI trap with Drop files

Version 1.8 (Beta 5) - January 2007: Additional help text & minor GUI fixes.
    -  DIRO option enhanced to allow Files only restoration
    -  Include/Exclude file mask logic tweaked

Version 1.8 (Beta 6g) - May 2007: Fixed bug in backing up and restoring with Encryption option,
    -  including changing the encryption template to allow calling a
    -  Rexx script so the dynamic encryption parameters could be logged.
    -  A sample Rexx script called "myencode.cmd" is now included in the package.
    -  (Note, any files previously encrpypted backups not compatible with this release,
    -   but I don't believe anybody uses that feature except me.)
    -  Minor change to Generational report output
    -  Including a sample Rexx script "restxmpl.cmd" as a shell in case somebody
    -  wants to understand the backup media in more detail and see how small files
    -  can be accessed. It is only for educational purposes.

Version 1.9 (RC1) - July 16, 2007: Externalized /WIPE option
    -  Recompiled (but untested) WIN32 version.

First time question and answers

*  Why non GUI?
 To keep things simple if you have to restore your system. By being a console application, very little intelligence has to exist on your computer should you need to perform a complete restore.

Also, as it is command line driven, it is easy to incorporate into other scheduling utility scripts that automatically run at certain times of the day.

*  What are the major modes of operation?
Backup (default operation), Restore (/REST), Reporting (/RPT and /DETAILEDRPT and /LIST), and manual maintenance (/DROP) mode.

*  Can it also do only a partial restore?
Yes. You can restore just one file, a subdirectory, a subdirectory and all subdirectories below that, only a subdirectory and not the subdirectories below that, only certain files matching a pattern, etc.

*  Can it back up long file names?
Yes. It creates backup file names with abstract 8.3 names, but remembers the entire name. It will also handle files with the same name from different subdirectories as the name on the backup media is this abstract 8.3 name.
Additionally, it can rename the shortened name to the long name should you have restored the system using an operating system that doesn't support the long name, and then boot to an operating system that does support long names.

*  How can I see what real file each backup file is actually backing up?
Two ways:
    Examine the "backemup.ctl" file for each entry, or
    Use the "backinfo.exe" program with the backup file in question as the first and only argument.
      For example, BackInfo a:\files\C0000007.001 

*  What else can BackInfo  do?
As previously mentioned, each file on the backup media has a header that can be used to identify the file (such as if one needed to reconstruct the "backemup.ctl" file for some unexpected reason). However, this header sort of gets in the way  of just copying the file straight from the backup media. Therefore, BackInfo  can be used with a 2nd argument to create new file someplace else without the header. If you've requested backups without encryption nor zipping  of the data, then this new file is in fact the file you wanted to recover. If you had asked for data compression during backup processing, then examine the header that is displayed and if it was indeed packed, then simply unzip  this file. The header info will also tell you if you needed to decrypt  the file first.
Therefore, if you are simply trying to get a single file from the backup media, BackInfo  can be used to examine and copy that one file to anyplace.
i.e. BackInfo a:\files\C0000007.001  c:\temp\filename
However, Backinfo  will not set the output file date/time nor attributes as a restore operation would have.

*  I notice backup file names are created in sequence. What eventually happens?
The backup file extension will count from 001 to 999 and then resume counting with 001. If you were keeping 2 generations when the wrap happened, the latest generation would be 001 and the previous would be 999 therefore don't assume the highest number is the latest version!
If you are backing up more than a hundred thousand different files (highly doubtful), the 1st character of the file name will increment, (i.e. from to D ) and restart counting from 1, thus you have another hundred thousand file sequence. This will repeat until the 1st character reaches Z.
The format of the abstract 8.3 name on the backup media generally follows this template pattern with the exceptions listed above:
    dccsssss.ggg
             |||  = generation number
       |||||      = file number (roughly a hundred thousand source files)
     ||           = reserved for tracking "chunks" of large split files
    |             = drive letter of source

*  Is temporary space required?
Yes, it is, and depending on the options (such as compress or encipher), various operations will use temporary files during processing. You must have the environment variable "TMP" defined an pointing to a directory of sufficient working space, and the path specification must use short names only. Some systems might have it set as "SET TMP=C:\WINDOWS\TEMP" which is perfectly valid if your C drive has enough working space. The temporary working space will be no more than twice the size of the current file that is being backed up. The temporary files are managed and automatically removed when that processing step is complete. Do not use a temporary directory that has any portion as a long name nor imbedded spaces. This is because we want to maintain the ability to use the DOS programs for some of the operations, especially in the case of catastrophic system failure.

*  Speaking of enciphering, do I have to worry about temporary file residue being left around. Could somebody undelete one of these temporary files and see something I didn't want them see?
When the encipher option is enabled, temporary files are overwritten with varying patterns to disrupt any residual magnetic patterns before finally being deleted.

*  One of my backup disks is bad, what should I do?
Format a new disk and put the backemup.id  file in the root directory making sure the correct volume id is the first field in that file. Although each removeable media backup disk is has a volume label too, it is not used by the program to identify the disks. It is only there for your convenience. BackEmUp will use the information inside the ID file for volume recognition.
Copy as many of the backup files from the bad media as possible. When this new disk is mounted during another backup operation where some normal files have changed, the program will detect the missing files and if they are for the most current generation, they will be recopied automatically. Note, you may insert the disk when the program is asking for any volume to back up to and it will go into the detection routine and mark the missing files as well as detect orphaned  files on the backup media. An orphaned  file is a file that follows the backup file naming convention and is present on the backup media but has no record in the control file. This could happen under a rare abnormal end situation where the backup control file was not sucessfully written. For more information refer to the /orphans  option.
If you mounted the wrong volume, BackEmUp  will reprompt you for the desired volume.
If you lost the very first disk of your backup set, remember that there is another copy of the BackEmUp.ctl  control file in the logical root of what you had backed up. i.e., if you had backed up c:\windows\* then the control file will also exist as c:\windows\backemup.ctl and provide you with an extra backup copy of the control file.

*  How do I interrupt (stop) the running program
Press the esc  key. Control+C will also work but that is not recommended as that key sequence may interrupt the compression or cipher program and not correctly terminate BackEmUp .

The esc  key may not function under Windows due to the way Windows handles the keyboard. Also, under Windows, use the Control+Break key instead of the Control+C key. If the compression or cipher user exits are being currently executed, Windows may not allow BackEmUp  to recognize the Control+Break sequence, so try repeatedly.

Special command line options

This is a short summary of some of the command line options. Entering BackEmUp  with no parameters will give you the compete list of valid command line options.

Control file special commands

By default, the control file is "backemup.ctl" and it exists on the backup media. A copy also exists on the hard file in the logical root of the backup source. This is a copy for reference only. The program uses the copy from the backup media for all operations, thus there can be multiple backup sets from the same source specifying different options. Therefore, if you make any manual changes to the control file, edit the one from the backup media, and save it as a plain text file!

The control file consists of one line records. Each record is identified by a type  as the first character. The following are record types:

Control file user exit templates

These are pattern templates allowing BackEmUp  to invoke the utility with the proper syntax. The appropriate substitution is made for these key strings:

Compression

For example, ZIP and UNZIP or other similiar command line utilities.
CMD_COMPRESS
CMD_UNCOMPRESS

Encryption

For example, BLOWFISH or other similiar command line utilities.
CMD_ENCIPHER
CMD_DECIPHER

These specify the system commands an options for these user exits. BackEmUp  will substitute strings for $archive, $file, $dir  during operation as appropriate. BackEmUp  has provisions for working around long name restrictions with a compression program. i.e. For the restore operation, BackEmUp  will use temporary files such that all intermediary operations use short file names and then put the final result into where it belongs with the appropriate long file name (if the operating system supports it). See the section on Disaster Recovery  for more information.

If the corresponding option is enabled, edit these templates to match your specific user supplied program parameters.

Explanation of the sample templates provided

Operating System differences

There are native versions of BackEmUp  for OS/2, Windows, and DOS. The only significant difference between them is in long file name processing and Extended attributes. As hardly anybody uses DOS anymore, and DOS has severe memory and resource limitations, BackEmUp  for DOS has been optimized for use during the Windows disaster recovery steps. Its control file read operation has been pruned to only consider files in the root and certain Operating system directories, such as you need to restore a minimal Windows system from the Windows Emergency Startup diskette. If for some reason you desire full support, use the /FULLDOS  option.

OS/2 can handle long file names even when booted from its disaster recovery floppy disks. Therefore, its compress/uncompress templates include quotes around the portions of the file names that could contain embedded blanks. This would only be a consideration if you are restoring compressed files to a different operating system, and it is simply managed by putting the correct compress/uncompress command templates into the control file.

OS/2 uses extended attributes whereas DOS and Windows do not have the concept. They will be lost if you backup on OS/2 and restore to Windows.

Disaster Recovery

Hopefully, you will never need these steps. This sections covers how to recover from a complete system failure. Typically, you would boot from floppy with your Windows emergency Startup boot diskette, access your backup media, and restore the system files using the /rest option of BackEmUp.

Alternatively, you may choose to use another backup program for your initial backup of your operating system, and only use BackEmUp  to manage select multiple generation backup of your data files. The multiple steps listed below to fully restore a completely destroyed Windows system may seem overly complex; but that is only because of the long file names of Windows vs the short file naming convention of the Windows Emergency Startup disk.

These steps listed below assume your operating system boot drive has been totally destroyed. Obviously, if it was another drive or just a subdirectory that has been destroyed, you can simply restore those files in one step as your operating system is still fully functional. Again, these steps below are shown assuming a total system failure.

Windows

Step 1: Windows 95/98 Startup disk

Make sure you have created a bootable Windows startup disk. (Use the control panel, install/remove software, and select the tab to create the startup disk.)

Note, when booted using the Windows Startup disk, you are essentially running DOS. This limits the programs that you can run until you get the rest of your system functioning. It would be a good idea to boot from the startup disk before a disaster to insure you have access to the devices you need, and if not, create the diskettes necessary to access those devices.

Step 2: Disaster recovery diskette

Insure that you have drivers installed (or available) to access your backup media. For example, if you are backing up to an Iomega Zip  drive, you may need to copy the guest software from the Iomega tools subdirectory: i.e. Copy the "guest.*", "*.sys", "*.ilm", and "*.mpd" files from the Iomega tools subdirectory on your hard disk to your disaster recovery floppy disk. This will allow you to access your Zip drive if your entire hard file has crashed and you have had to boot from floppy using your Windows 95 Emergency Startup disk.

If you are using compression or enciphering extensions, make sure those programs are also copied to the disaster recovery diskette along with the BackEmUp and BackInfo programs for DOS (as the Windows 95 emergency startup disk is not a fully functioning Windows 95 system) as well as the Windows version of the BackEmUp  and BackInfo programs.

If you have the capability, you could considering creating an inactive volume on CD-R (or CD-RW) for the files needed to restore the operating system, and put all the tools on the CD. The Windows 98 Startup diskette has built in CD Rom support whereas under Windows 95, you would have to add those CD drivers manually.

Step 3: Restore the critical operating system files

Step 3.1

You will boot from floppy using your Windows Startup Diskette.

Check the hard disk for errors and correct them before proceeding any further.
Depending on the type of disaster you experienced, you may have to reformat (i.e. format c: /b  ) or repartition your hard drive, or issue the sys c:  command. You should not attempt to change drive characteristics. If you do reformat the boot partition, remember that Windows 95/98 is a DOS extension and DOS requires certain files to be in the root directory in a specific order. The format c: /b  command will reserve space for the special files allowing BackEmUp  to restore them to the proper location. Alternatively, the format c: /s  command will put DOS files in the correct order, but when you restore the windows components, be sure to specify the /replaceall  option so these files will be corrected for a windows boot. This can the initial problem if you find that (1), you can't boot the drive at all, or (2) when it boots, it only starts to a DOS command line and not the graphica Windows GUI.

Step 3.2

Next, using the DOS version of BackEmUp , you would restore (using the /rest option) the boot/hidden/system files in the root of C:\ as well as the "Windows" subdirectory.
i.e. BackEmUp    C:*    x:    /rest /replaceall

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

The DOS version has been tweaked to only consider the appropriate files for restoring a minimally booting Windows system.

The reason behind this DOS step at this point is we want to restore the system and bootable files in the root along with the Windows system files, but we don't want to restore the rest of the system as there could be a naming problem switching from short names to long names once we get a bootable Windows system restored. And as we've had to boot using the emergency Startup Diskette, long file name support is not available. So at this point, we are just going to restore the bare minimum to get the system to boot from the hard file to a minimally operating Windows GUI.

Note: Files in the C:\ root directory and in C:\WINDOWS are never compressed to facilitate this reload step. However, you may need those decompression program files to do a full system restore after you reboot for step 4, so make sure you have them handy.

Step 3.3

Note, at the end of this step, there should NOT be a "Start Menu" subdirectory: i.e., the "C:\WINDOWS\STARTM~1". If so, delete it and everything below it. Why is this necessary? It appears the Windows will automatically create this long name when it boots in the next step. If it does create one, it will have a short name of "STARTM~2" which will mess up the remainder of the restore operation.

By default, the tweaked DOS version of BackEmUp  should not have restored it. If it does indeed exist, you can easily do this deletion by changing to "C:\WINDOWS\COMMAND" subdirectory that you have just restored and issuing "deltree C:\WINDOWS\STARTM~1" 

When the system boots from the hard drive the first time, Windows will create a dummy empty one with the correct short and long names. Then when the next step runs under full windows, it will put the correct items back under the "Start Menu" subdirectory.

Step 4: Restoring the rest of the system and long file names

After rebooting the minimally restored system, windows may struggle up the first time or two, so if Windows fails to boot, try booting again. You may have to do this a couple of times as Windows struggles to come up with this minimal file set. If you have a network card, you might want to temporarily remove it. Eventually, Windows will come up to a very minimal desktop that may appear to have missing and/or wrong images for icons. This is normal as we've only partially restored the system so far.

You will need to get to a command prompt. This can be done even though the system is only partially restored. Simply select "run" from the Start Menu and browse up to "My Computer" then the "C:" drive and select "command.com" as the program to run.

Step 4.1

Booted up from the minimally restored operating system files on the hard disk, run the Windows version of BackEmUp  to rename the files we just restored using short names, to the full long name version of the file.
i.e.: BackEmUp C:*    x:    /rest /rename to rename (for long file names).

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

If during this process you get a message about "invalid command interpretter", you should issue:
BackEmUp C:\command.com    x:    /rest     /replaceall
to restore the command interpretter again and reboot.

It is normal to receive many "file not found messages" at this step as you have only restored part of the system!

Examine the system for any incorrect long name/short name aliases and correct before going any further.

Step 4.2

Reboot Windows again to make sure it is "clean".

Finally run the Windows version one more time to restore the remainder of the system using the long file names.
BackEmUp C:*    x:    /rest

This will correct the icons on your desktop as well as fill in the programs in the Start Menu.

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

Miscellaneous notes

Depending on what you have done to your system, a long file name at this point might have a different short name that it originally had due to pecularities of Windows. i.e. "A Long File Name" may have originally been equivalent to "ALONGF~2" depending on many factors, but this restore step may create the equivalence as "ALONGF~1". However, the system should function correctly.

Your desktop may appear different and many of your menus may be empty during some of these intermediate steps, but don't worry as you've only restored part of your system in the early steps.

During the boot process, you may experience error messages from the system trying to find application installed drivers that you haven't restored yet. If these are preventing you from booting to a functional MS-DOS prompt from within Windows, then repeat step 3 but restore the specific files Windows is complaining about. If the errors are non fatal, ignore them for now as you attempt to restore the rest of your application files.

Step 5: Reboot your system

Your operation system and files on the boot drive should now be fully restored. Your desktop icons should appear as what you've been used to seeing before your disaster. It may require that you actually double click on the icon for it to change correctly, but that would be a one time act.

Check the system for any errors.

Step 6: Restore any other drives that may have been damaged

For this step, you don't have to do anything complex; for example, just run
BackEmUp d:\path x: /rest  where d:\path is the drive and path of the files that were backed up, and x: is the drive of the backup media.

OS/2

OS/2 is much easier to restore as the emergency startup disks already know how to handle long file names of the HPFS file system. However, here are a few minor things to consider:

Step 1, OS/2 Utility Boot Disks

The standard utility disk set does not include some utilities that could be very useful during disaster recovery.

If you are using a ZIP drive, you'll need to include those drivers during floppy boot up sequence. As OS/2 boot from floppies includes CD Rom support, a good alternative, is to create an inactive volume on a CD R/W that not only contains the backup files, but also various utilities and backup programs mentioned.

Step 2

Boot from the Utility disks. As necessary: create partitions, Boot Manager, logical volumes, format the drive, etc.

Step 3

Copy the files from Utility Disk 3 to a temporary directory on the hard file and change to that temporary directory. This improves performance greatly as BackEmUp  may invoke these programs several times during the course of the restore.

Make sure the TMP  environment variable is set to a R/W subdirectory that has reasonable free space.

Restore the files.
i.e. BackEmUp    C:*    x:    /rest

where x: specifies the drive (and optional path) to the control file.

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

Step 4, Final step

Remove any floppies and reboot from the hard disk.

Partial Restore

Restoring a pattern

Let's say you made some change to a bunch of files. You can restore only those files, but if they don't fit one mask definition (for example: xyz*.txt) you will have to do multiple restore commands. If however they all fit a pattern, you can restore them all at once. For example, lets say you made some programming change to a bunch of cpp files but decided that was a bad choice and you want to back those changes out. Perhaps an example will help:

Assuming the following directory structure:
d:\other
d:\project
d:\project\support

You have backed up the D: drive (i.e. backemup d:\ a: )

You have many cpp files, some in project, some in support, and some in other, but the ones you are interested in are in project only.

issue backemup d:\project\*.cpp a: /rest  

This is an explanation of what that does: Although you backed up the entire d:\ drive, you only want to consider the *.cpp files in the project  and lower subdirectories.

Suppose you issued instead backemup d:\*.cpp a: /S1 /rest  
The /S1  option is what restricts the restore operation to only the *.cpp files in the 1st level subdirectories. You will not restore anything to the support subdirectory however you will restore files to the other subdirectory as well as project.

The /replaceprompt option can give you additional flexibility. Be sure to refresh your memory on all the /replace.... options to see what will serve your purpose the best.

The options may cause you to have to think about it just a little, but you can always use the /redir path  option to redirect the files to another temporary location to test out what you are really asking for. If you do specify a redirection path, it must already exist. i.e you asked for /redir C:\TEST  then you should create "C:\TEST" before you start to run BackEmUp . It will create all the subdirectories under C:\TEST relative to that new logical root.

Active vs  Inactive volumes

What are they and Why use them

An inactive volume maintains backup files that are tracked by BackEmUp  but are never automatically dropped as they age. (Note, refer to the /purge  option to alter this behavior.) Thus, a CD-R is a perfect media as once they are written, they are remembered forever. However, writing a CD-R often requires special software or hardware that may not be physically on the machine you wish to backup.

Inactive volumes can also be used to consolidate multiple R/W media (such as multiple ZIP or Floppy disks) onto one larger media such as a CD-R. This can be useful if the majority of your files rarely change, but changes do happen over many directories of the disk you are backing up. For example, the boot drive of an operating system. Once installed, many of the operating system and application program files will rarely, if ever, change; but there may be INI or configuration files that change frequently. Using the inactive volume concept, one can burn a CD containing the baseline of the system and remove those backup files from the normal backup media. This can also be used where you are backing up to another drive, such as a lan alias, and wish to reclaim the space used by these seldom changing files.

In cases where you have no efficient removeable R/W media, you can initially back the system up to another spot on the hardfile, burn a CD-R with those files, then move backemup.ctl  file to another media such as a floppy, and continue making incremental backups to floppy disk.

The mechanics of inactive volumes

The backemup.ctl  file maintains a list of volumes and the amount of free space. Each volume is logically identified by the contents of the backemup.id  file that exists on each volume. That identifier is the first field of the single line that exists in the backemup.id  file for that volume. So it would follow that as long as we keep each logical volume in its own subdirectory on a combined larger media, we can maintain the backup management philosophy as tradition "disk labels" are not used for identification.

In the backemup.ctl  file, an inactive  volume will have a -1  for the amount of free space available. Thus, this volume will never be asked for during a normal backup proceedure as it has no free space. The -1 also tells BackEmUp  that there will never be obsolete files  on this volume. During restore, this -1  free space signals BackEmUp  to ask for an alternate path to mount this media. Thus if you had backed up to floppies as A: but have created a consolidated inactive backup media on CD-R, you can tell BackEmUp  to look at your CD Rom drive to read the files. Obviously, if you were backing up to floppies, you would not want to create a CD-R for each and every floppy! As the logical volume is identified by the contents of the backemup.id  file, you would consolidate many floppies into individual directories on the CD-R and point to the appropriate subdirectory when asked.

Proceedure to set up to use inactive volumes

If at this point you are switching from backing up to a non removeable media to a ZIP or floppy drive, copy the backemup.id  file and backemup.ctl  file to the new backup media. Besure to edit the "! REMOVEABLE_MEDIA" line in the control file (or remember to use the appropriate /rm- option next time).


The BackSig  program

BackSig  is a simple utility to verify the integrity of a list of files. It computes various check values (signatures) that can be manually recorded and compared. For example, if you just moved the "FILES" subdirectory onto a CD-R and want to verify the contents were written successfully, one could create a list of the files you moved (for example, use the standard DIR command with the appropriate /f or /b   option and redirect the output to a file) and manually verify the check values between the 2 physical media. If the computed check values are different between the two media, then the copy was NOT created successfully.

Hint: The /a:-d /o:n /s options of the standard operating system DIR command are also handy when generating file lists.

The program takes one parameter that is the name of the file containing the list of files. For example, create a file FILELIST.TXT and in it, list
C0000001.001
C0000002.001

Run BackSig FILELIST.TXT  and you could see output resembling:

Selecting files from list: filelist.txt

Files: 2 Total Bytes: 974

Begin file contents examination phase...


Check 1, 22 7432 5914
Check 2, 26 7177 2008
Check 3, 5 6203 6552
Aux key: 9Q6V XJ4

Hint: Use standard file output redirection to save BackSig  output to a file, and then use any one of a number of standard file comparison programs.