Menu
▾
▴
#17 inacurrate time/counts in mbout sta
Noticed with 1.0.7 that the o/p of mbout sta is wrong by both time and size for files at least where files also includes the .tic file/s related to them.
Example for 2:230/150:
bash-4.3$ mbout sta
MBOUT: MBSE BBS 1.0.7 Outbound Manager
Copyright (C) 1997-2017 MBSE Development Team, All Rights Reserved
flavor try size age address
...H.. 3 394726 2/19h 2:250/2@fidonet
...H.. 0 5236 6:40m 2:250/25@fidonet
...H.. 0 51386288 7/03h 2:230/150@fidonet
...H.. 0 8624 3:08m 2:250/9@fidonet
...H.. 0 7204 26:39 2:250/4@fidonet
-bash-4.3$ cat 00e60096.hlo
#/home/mbse/var/bso/outbound/0014ff6b.we0
@/home/mbse/ftp/pub/gfd/net/misc/SAMBA130.ZIP
^/home/mbse/var/ticqueue/475732c4.tic
-bash-4.3$ ll ~/ftp/pub/gfd/net/misc/SAMBA130.ZIP
-rw-r--r-- 1 mbse bbs 25690887 May 18 10:15 /home/mbse/ftp/pub/gfd/net/misc/SAMBA130.ZIP
-bash-4.3$ head ~/var/ticqueue/475732c4.tic
Area GFD.NET.MISC
Origin 2:2490/3045
From 2:250/1
Replaces samba130.zip
File SAMBA130.ZIP
Lfile samba130.zip
Size 25690887
As you can see the file SAMBA130.ZIP is counted twice once for the tic and again for the file !
Time well it is 1 day so that is wrong too. HE did poll 24-May at 08:04 as it is now 25-May at 14:00 the figure is clearly wrong.
Like wise with 2:250/2 but the error seems to be silightly different as showing 394k on hold with :
-bash-4.3$ cat 00fa0002.hlo
@/home/mbse/ftp/pub/ifdc/fg_worf/FILEGATE.ZXX
^/home/mbse/var/ticqueue/475731b3.tic
#/home/mbse/var/bso/outbound/0000ffff.we1
#/home/mbse/var/bso/outbound/0000ffff.th0
-bash-4.3$ ll ~/ftp/pub/ifdc/fg_worf/FILEGATE.ZXX
-rw-r--r-- 1 mbse bbs 54206 May 22 18:11 /home/mbse/ftp/pub/ifdc/fg_worf/FILEGATE.ZXX
-bash-4.3$ head ~/var/ticqueue/475731b3.tic
Area FG_WORF
Origin 1:261/38
From 2:250/1
Replaces filegate.zxx
File FILEGATE.ZXX
Lfile filegate.zxx
Size 54206
-bash-4.3$ ll 0000ffff.we1
-rw-rw-r-- 1 mbse bbs 101082 May 24 23:26 0000ffff.we1
-bash-4.3$ ll 0000ffff.th0
-rw-rw-r-- 1 mbse bbs 42010 May 25 13:55 0000ffff.th0
The size error is even larger and the time is also incorrect by some hours.
So timing is wrong and files with a .tic are size dupped including the msgs by x2.
This is NOT a new error for 1.0.7 as it has been there a while :(
Vince
Diff:
Noticed today with node that having sent all on hold two days ago it is now reporting :
...H.. 0 33010108 10/20h 2:250/9@fidonet
so silly amount on hold but 10 days ?
Applies to v1.0.7.11.
Last edit: Vincent (Bryan) Coen 2019-01-09
This error could be that mbse is counting the same files twice as files and file names inside a .hlo.
Time issue is possibly linked to above but not at all as to how.
Still present on current version 1.1.0
Still present for 1.1.1 BUT I have now written a program to deal with all these issues with some extra features like
1. Size are human readable with k and m signifying Kilobytes and Megabytes with option of not doing so (option B) .
2. Show Connect Error codes and the text (option E).
screen 1 mine as mboutq and 2 - mbout sta
Oops forgot the screen grab for mboutq E
I spot checked several of the nodes in your screen shots; the MBOUT numbers
divided by 1024 match exactly the numbers your program shows. I do like
how your program sorts the output, and the option to display errors if
present. I'm considering adding those to MBOUT when I get sone time to
work on it.
Andrew
On Wed, Jul 9, 2025, 3:50 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
Related
Tickets: #17
What you did not mention was that the sizes and ages are accurate as mbout mis-uses such and in many cases uses the wrong values such as the date of the ?lo and ?ut files which is totally wrong and double counts files on hold not including the size of the TICs etc.
There are other possible errors that I gave up looking for but give me a shout and I will supply my source code but be warned, it is written in Cobol.
Nuts I will add the current version here along with associated documentation etc as attachments
Using the date of the .?lo files to determine how long files have been queued for a node is not wrong. In fact, it is likely more accurate in cases where a node only has files queued without any packets or ARCmail bundles. The date/timestamp of files that have been hatched into file echoes is not correct to use, as too often these dates/times are changed when the files are sent between systems, converted to new archive formats, or similar manipulation that takes place on many nodes.
The .?lo file is removed once all of the files in it are transmitted to the remote system and acknowledged. Then a new one will be created the next time a file is queued for that node.
I am currently working on a thorough review of the code that produces those outbound statistics. It would be helpful to know if your system uses any of the following:
Regards,
Andrew
No, using the create date of ?lo / ?ut files themselves is wrong as new files can be added at any time up to the date/time the file is removed which I assume is during the midnight running script.
I admit that using the create date of ech file CAN be wrong if sysop changes the archive without using the original date but as far as I know I do retain it.
I hav gone through all files for some nodes that have a lot on hold due to being not pollable and the ageing is working correctly - at least for me and the total on hold is correct.
Regards your questions : mboutq does not use file boxes nor TMail as mbse does not require them to work correcly so for my system I have not set them up now but I did at some point but found other issues although I have forgotten what these are and reverted to not use these sub features as the system work without them all.
Directory sessions via ftp - there is no direct link between ftp and mbse that clears down sent files as far as I can tell as ftp server does not talk to mbse but in any event I have no one using that facility to get on hold files but do have them grabbing files and the same applies to doing the same via httpd. In the case of ftp I keep track of downloads using the xferlog file and access.log for httpd.
To add in your options 1, 3 I would need to read the mbse data files and understand their make up data layout wise and how they interact with each other.
I did consider it to get the active nodes network and zone but it was easier just asking for the information when first using mboutq and storing it in a cfg file as this is needed to process the folders outbound.??? etc. This was this infor can be in more than one mbse datafile and I did not know what one was the file to use.
Another possible mbse update was to migrate the data files over to sqlite or mysql etc but a simple look at one or two programs and the way they did file i/o and the fact they are not using common file processing code that is called, I discontinued that idea as far too much work for my old brain (78) .
My own major systems do use common routines (a F.H. File Handler and that in turn can call a DAL if user is using Mysql RDBMS) to process each data file type so it only requres a call to a routine to process a file and therefore any change to the data structure just requires a routine change for the
FH, DAL (may be) and the copybooks used for each application program / module a lot easier and less time to program etc.
The create date/time of the .?lo file is the time that the first file was
queued for the destination. Since the objective here is to know how long
the oldest file has been in the queue, that date/time is as close as we can
get without redesigning the entire outbound structure. Granted, it can be
off some if the transfer is aborted after that first file is sent, but
others remain in the queue. I will look at your program to see what
differences you have in how you figure aging.
Andrew
On Thu, Jul 10, 2025, 7:47 AM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
Related
Tickets: #17
The .?lo files are removed when all files listed in them have been sent.
They don't remain until midnight; only the truncated ARCmail bundles do.
Andrew
On Thu, Jul 10, 2025, 7:47 AM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
Related
Tickets: #17