#42 File Group processing menu->10.1
I have posted this in the echo some time back, but now it is getting dangerous.
Using file group control in mbsetup via 10.1 I now have multiple copies of MAINFRAME area - see screen shot. Only a few minutes earlier I had four copies of group LNX4 which I was trying to delete and finally did it only for 2 copies of area MAINFRAME.
mbsetup is now totally messing up one or more (mbse) data files for which there is no recovery.
All this on v1.0.8 on Mageia v8 X64. I have no idea what other areas it has over written with all this and exiting mbsetup and reloading does not help.
Has there been some coding changes to the file group table and file processing from 1.0.7.22 onwards ?
I can not risk any more attempts and removing or even adding a new file area to the system.
I'm having difficulties replicating this behavior. It does not save any changes until you go to the preceding menu (via -) and the code for handling that behavior has not changed since 1.0.7 beyond minor things -- the logic itself remains the same.
Could you try editing and causing the behavior then looking into all the log files for any anomalous entries?
If I go into mbsetup .10.1
I show TWO instances of area MAINFRAMES.
Now I did do a site.doc generation.
I did the same a couple of months earlier.
I can provide both if it helps.
Annoyingly none of the logs files are used by mbsetup.
Also there is no tool within mbse that analyses the mbse data files so I
cannot even check them.
Possibly another reason for changing the system over to use SQL DB such
as SqlLite or MySQL / Mariadb etc. Where full logging was set on.
I am guessing that the internal copy of the data file for fgroups.data
Looking at this file just using less I see 3 instances of MAINFRAME but
with 2 showing the same file path area and the other one with a
different one.
Any of this help ?
Can you make use of any of the data files etc ?
Vince
On 02/07/2022 19:33, Michael Dillon wrote:
I would be able to use the data files, yes. There are a few log hooks in mbsetup but they're far and few between. Right now, when you make a change to the database, it prompts you if you want to write and it will overwrite the original with a temporary work file. It's possible something is running amok during that or in the handling of the temporary file -- though I'm not sure what would've changed since I only addressed more minor issues -- but anything is possible.
On 03/07/2022 03:02, Michael Dillon wrote:
How do you want me to send you the .data files and what one's do you want ?
Vince
Judging by the error I am guessing that it is over writing/updating the
wrong area in WS i.e., for another area.
Looking at the data written out (using less) it seems that the area name
is overwritten but may be not the path for the area. I did not look at
any other possibly data fields.
On 03/07/2022 03:02, Michael Dillon wrote:
There are always possibilities; the files that I may need to diagnose it are: nodes.data, tic.data, and fgroups.data (the other two are inquired when reading fgroups). You can send them via email if you prefer not to attach them here.
The easiest way to send it via email would be mike at mbsebbs.org
I was able to read the files just fine, I can see the duplicate entries and the system does prevent their removal. I could write a utility to remove duplicate entries in this case or somehow add a feature to mbsetup for error checks of sorts (will take a while). The bigger question is how did extras get in there and I'll take some time to analyze what inserts entries into the filegroup and how it checks (possible it doesn't check for existing entries).
On 05/07/2022 20:36, Michael Dillon wrote:
Possibly reasons :
Memory leaks.
Inadequate memory reserved for task.
Memory used is over written by other task or fields or record/s.
This report was after other instances of similar when deleting other
file groups from the system that had become redundant and I had to
remove all links to any associated file areas first.
Removed 6 - 10 File groups during the session when this problem re-appeared.
Seem to recall but not confirmed that when this issue appeared before I
did remove more than one group.
Vince
I have gone through the files that touch or edit fgroups.data in any way. Any changes most had were superficial and did not affect the logic or behavior of those code pieces (such as removing a superfluous include). Most of the files prior to that were not touched since 2015, long before the 1.0.7.22 release back last year. Most of my changes post-date that as well and are of the 1.0.8 branch. Of the few spots that do alter the data include:
mbfido's rollover -- only adjusts counters for files and kilobytes before overwriting the existing record.
lib/dbtic.c -- Used only when processing tic files and only updates files and kilobyte counters if they changed.
The rest occurs in mbsetup for editing file groups. There's appending a new group which is a blank record, editing an existing record (or new blank record), and opening or closing the file (upon closing, the temporary file overwrites the original). I ensured that the sorting system for the databases has no issues. At this point I cannot find a single direct cause of entry duplication in the few places the file gets written. This of course doesn't preclude the possibility of multiple writers accessing the file but that is hard to test.
The most I can do is create (for simplicity's sake) an alteration in the menu to check and delete duplicates or allow you to delete an entry if a duplicate of it exists elsewhere (which might be the least intrusive).
Note that the duplicate MAINFRAME areas I strongly suspect are over writes from other file areas and sorry no, I do not know what ones were overwritten (if at all).
All very confusing.