| |
VK3AEO > TPK 09.08.97 13:42l 66 Lines 3370 Bytes #-10473 (0) @ WW
BID : 756_VK3AEO
Read: GUEST
Subj: More:- 2QN's Don't let this happen
Path: OE3XSR<DB0WGS<DB0RGB<DB0MAK<DB0HOT<DB0LPZ<DB0ERF<DB0HSK<PI8DRS<ON4RAT<
DB0ACH<DB0RWI<PI8JOP<PI8ZAA<PI8HWB<ON6AR<F6CNB<VK3BBS<VK3KSD
Sent: 970808/1844Z @:VK3KSD.#MEL.VIC.AUS.OC #:58878 [Somerville] FBB7.00c
From: VK3AEO@VK3KSD.#MEL.VIC.AUS.OC
To : TPK@WW
VK3AEO/TPK 1.83 Msg #:756 Date:08-08-97 Time:18:43Z
Greetings
More to John, VKL2QN's observation on a great program TPK..
As John Points out do regular housekeeping always leaving some working
disk space, not only for files but also to allow your Lists file to grow.
If you run out of disk space, John has pointed out the problems re fetching
files but it also applies to just receiving the FBB lists update.
Consider a full disk; and the list file wants to update, so not only
can it not add to the list file, the NEXT list number cannot be updated.
As soon as the next greater header number appears, your system will send a
re-sync, the BBS goes back and again your list file cannot accommodate the
headers, and so your system will continue to loop with the BBS being forced
back to the same re-sync number.
However, Not only is your system stuck in a going nowhere loop, The BBS
cannot progress with header updates for all others on the frequency simply
because of a user's FULL disk.. This obviously frustrates the Sysop and
those on frequency. I got caught, and being present, got of the
Frequency smartly, then travelled the same path as John, using Pctools to
clear some rubbish out etc and all returned to normal. I Also experienced 2
users on different occasions causing the BBS to loop, one lasting aprox
8hrs. Very Frustrating.. Working out who is at fault is another story hihi.
BUT there is yet another way you can shoot yourself down and appear to
have crashed!!! But not so, just a ruff landing hihi..
Each time you delete headers from the HEADER file, either automatically
on startup or manually, you MUST have enough disk space to contain the
shorter file. This happened to myself like this.. :-
Manually you might have entered:- BR VK3KSD E DATE 970424
to delete from the list , headers older than 24th Apr 97
TPK appears to rename vk3ksd.LST to VK3KSD.BAK then proceeds to copy the
.BAK file to a new vk3ksd.LST file, meeting the current delete criteria and
thus generating a new file, then given that all goes well TPK deletes the
.BAK and you are none the wiser. BUT if it crashes, (due to disk space) you
will find the .BAK file and the PArt built NEW .LST file.... and again in
trouble.
The immediate fix is to delete the Part New file, rename the .BAK file
to its original file name, ie VK3KSD.LST Restart TPK to ensure all is ok.
Within TPK delete/(copy to floppie) enough messages or downloaded info to
enable the failing task to have sufficient room to be completed. This might
mean deleting other unrelated packet software/files from your disk.
Your MESG_PRIV file will probably follow the same procedure..I believe
the Author had this protection in mind when the program was written..
THE MORALE here:- Maintain AMPLE disk space at all times...
Particularly if your system is on 24hrs or unattended.
With all due respests to the above, TPK is a great program, easy to setup
and operate with ample automatic flexability and while there are a few
disk activities I would like changed, (I note other similar Programs are
the same ), TPK is my preferred packet system. Meanwhile, I hope my
info is of some help...
Regards de Ron
Read previous mail | Read next mail
| |
