🚀 go-pugleaf

In article <1254@watserv1.waterloo.edu
> bmaraldo@watserv1.waterloo.edu
(Commander Brett Maraldo) writes: 
> 
> What a wonderful set of back-up programs!  I am refering to the 
>recently posted Vault and Key programs.  The Vault workes wonderfully, 
>packing diskettes completely.  The Key, ont he other had, didn't work all 
>that well.  The first time I tried to unpack my 'vualted' disks the hard 
>drive sat there cratching in the middle of my C:\TEX\TFM folder.  I tried
>again it there wern't any errors but the C:\TEX folder was not there
>even though The Key said it wrote the relevant files.  I did a 'Show Info' 
>on C:\ and it acknowledged the space that should have been used up 
>by C:\TEX (about 5 meg was missing!).  So had to zero the drive and 
>manual load the files, sigh!  I'll try another back-up and see if it works, 
>but I'll be damned if I am going to trust The Key to unpack my files (to 
>test a full back-up I had to zero my C:\ partition; if The Key is indeed 
>buggy then I'll have to spend hours again reloaded the drive manually). 

Sorry you had problems with The Key, but I can't imagine anything The
Key is doing that could cause the problems you describe.  The Key
doesn't do any fancy buffering like The Vault does.  It is basically
just a file copy program that uses the standard GEMDOS calls to create
the files.  The only thing special that it does is to look for long
files that The Vault has split into pieces and put them back together
again.

I can think of one possible explanation for your problems, assuming
you are still running TOS 1.0 or 1.2---the so-called "40-folder bug".
What happens in the old TOS is that every time a folder is "touched",
some memory is allocated from an internal memory pool and never
released (until the disk is ejected, in the case of a floppy).  A
folder is touched when you display it contents or search through it
(or possibly even when you display its name -- I'm not sure about
that).  In any case, the internal pool is only large enough to safely
accommodate 40 folders.  When the pool is exhausted, the old TOS
doesn't report an "out-of-memory" error but begins overwriting other
memory, which leads to all sorts of weird errors, including trashing
your disk.  Using FOLDRXXX.PRG increases the size of the memory pool
but does not fix the bug.  Thus, FOLDR100.PRG adds memory for 100
folders, so now the problem may strike after you have touched 140
folders. 

Even if you do not normally run into this bug, you are likely to
encounter it when rebuilding your hard disk, because that is one time
when you touch every folder on the disk, and even worse, you are also
touching a lot of copies of those folders on the backup disks.  I
recall similar things happening to me a few years ago before I had TOS
1.4 when I tried to rebuild my hard disk.  The "cure" is to rebuild
the disk a piece at a time and reboot after each piece.  Also, be sure
to run FOLDRXXX.PRG with a large value for XXX each time you reboot.
With these precautions, you should be able to rebuild your disk
successfully.  The same applies whether you use The Key or do it
manually---the problem is in the old TOS, not with The Key.

By the way, I vaguely recall that one of the manifestations of the
40-folder bug is that files or folders would seem to disappear but
would reappear when the machine was rebooted.  Thus, if you do
encounter such problems again, it is probably worthwhile rebooting
your machine to see if the files come back before zeroing your hard
disk and starting all over again. 

Please let me know if you continue to have problems with The Key
even with these precautions.

==================================================
| Michael Fischer                                |
|    Arpanet:    <fischer-michael@cs.yale.edu>   |
|    Bitnet:     <fischer-michael@yalecs.bitnet> |
|    UUCP:       <fischer-michael@yale.UUCP>     |
==================================================