Brian,
OK, please ignore my earlier stupidity. Erasing plays vs deleting plays are not the same, and I forgot to use the Cmd-D.
Anyway, when I did do that there appears to be a real difference between the way v2.3 handles the deletion and v2.4 does.
Yes, early in the file the difference is easily seen in the total numbers of plays.
However, ONLY in v2.3 does the play name actually disappear from the playbook. It remains in the v2.4 playbook with NO OTHER difference in the file other than the total numbers of plays.
So, if in the course of checking the program reads there are two plays the analysis proceeds via play 1 then play 2, skipping the last play.
Below is the data showing what I mean...
Welcome to the PMFB Playbook Checker, please select a league in the Check Playbooks menu and a report type in the Reports menu to begin.
Checked file -> Test Remove All Plays Total Plays: 3 Off Plays: 3 Def plays: 0
League ID = NCFL
Play #: 1 Play type: Offensive Play ID: Crossing Screen L Play is a Pass
Play #: 2 Play type: Offensive Play ID: HB Goal Screen2 Play is a Pass
Play #: 3 Play type: Offensive Play ID: Jaws of Steel R Play is a Run
--> HB got the handoff...
Checked file -> Test Remove -2 Plays Total Plays: 2 Off Plays: 2 Def plays: 0
League ID = NCFL
Play #: 1 Play type: Offensive Play ID: Crossing Screen L Play is a Pass
Play #: 2 Play type: Offensive Play ID: HB Goal Screen2 Play is a Pass
Checked file -> Test Remove -3 Plays Total Plays: 2 Off Plays: 2 Def plays: 0
League ID = NCFL
Play #: 1 Play type: Offensive Play ID: Jaws of Steel R Play is a Run
--> HB got the handoff...
Play #: 2 Play type: Offensive Play ID: HB Goal Screen2 Play is a Pass
Test Remove Plays has all three plays, Test Remove -2 Plays was the result of v2.4 deletion and Test Remove -3 Plays the result of v2.3 deletion.
The deleted play was the Crossing Screen L play.
This is the lead in to the playbook as seen by HexEdit (bytes 000 to 090, playbooks in order as above (All, -2 then -3)...
00 03 00 03 00 00 00 00 07 00 00 00 00 00 00 00
00 02 00 02 00 00 00 00 06 00 00 00 00 00 00 00
00 02 00 02 00 00 00 00 03 00 00 00 00 00 00 00
So reading the BookCtrlType record doesn't help, it properly reads the total number of plays, but the inclusion of the deleted play in the playbook in v2.4 offsets its removal.
This should clarify things, at least from my perspective.
Also, I just noted in reviewing thsi mail that the v2.3 playbook moved the last play into the deleted play's spot, or so it would appear.
Rick
Rick,
when you delete a play, 3 values should change in a v2.x playbook. If you refer to the header record pasted below, the NoRecs field (total records [plays]) decreases by 1, the NoOffRecs field (offensive records [plays] - assuming you deleted an offensive record) decreases by 1, and one of the bits in the bit-array represented by InUse[32] is set from 1 to 0. That's all that happens. The Windows versions have always worked this way. Now that the Mac shares the same code base, v2.4 for Mac works this way too. All your software needs to do to see if a record is valid (i.e. not deleted) is check one of the corresponding 256 bits in the InUse field.
"Playbook header record"
struct BookCtrlType {
void Init();
void ByteSwap(bool p2c=true);
short NoRecs;
short NoOffRecs;
short NoDefRecs;
short FirstRec;
unsigned char [color=Red]InUse[/color][(MaxPlays-1)/(sizeof(unsigned char)*8)+1];
S15 VersionID;
ProtectRec Protection;
short AudibleID;
short AudibleRecNo[3];
};
OK, step by step...
PMFB v2.4 (Mac or PC as best I can tell work identically)
1 - Open any playbook.
2 - Delete a play, offense or defense.
3 - It does NOT show in the playbook now.
PMFB v2.3
1 - Open same playbook, the deleted play does not show there either.
HexEdit or my PB Checker
1 - Run program (use HexEdit), it asks to open a file.
2 - Choose the playbook in question.
3 - Search for the deleted play by name.
4 - It finds it still in the playbook.
Optional, using Terminal in OS X.
1 - Navigate to folder where playbook is.
2 - enter grep "play name" "playbook's name">Found_Play.
3 - enter view Found_Play.
4 - It lists the playhbook as containing the search string.
Also note, this can be used for a series of playbooks and it will list in the file only those playbooks that have the play in it.
Now my understanding from you is that once the play is deleted it is gone, no further reference to it should be found.
Is that incorrect?
Also please note, I have not even mentioned my program, which uses your header file. It reads the total number of plays, the offensive and defensive plays numbers, then it goes through each record.
What happens is that even if the reference is removed from the total plays and specific play type it reads to the number listed and then stops. EVEN if there are more plays left because of this issue. Or stated slightly differently, it reads that there are n-less plays, it reads to the total listed including the ones supposedly deleted that are not deleted, not reading plays that are still undeleted.
I can send files as necessary.
Rick
Richard K. Prescott
The fact that PMFB v2.3 and v2.4 no longer show the play tells you that there is a way to tell that the play has been deleted. Every single play record in the v2.x file format has a corresponding bit (flag) which tells you whether that record is valid or not. Regardless of what data might be left-over in the record, that bit is to be trusted as the final say whether the data in the record is real or not. The bits I am talking about are all strung together in the "InUse" field of the header record.
I understand that you feel the data should be wiped out entirely. Though I think you have a case for that on security reasons, I'm not sure whether or not the application ever worked that way. Regardless, for now, you should honor the InUse bits, and the issue goes away entirely in the next file version. Let me know if that doesn't clear it up.
Brian,
Regardless of the "in use" bits, PMFB used to wipe the play record.
And at least v2.3 does it after the following steps.
Run v2.4, delete selected plays. Now we know that this does not remove anything regarding the actual play, it still sits there taking space.
-- The play does not show up in the PMFB v2.4 play list.
Run v2.3, again the plays don't show in the play list.
Now, if you take a play that does show, make even one modification to force a rewrite of the play some interesting things happen.
Those plays that showed previously by all methods EXCEPT PMFB are now gone.
So it is whatever was done to the file structure in v2.4, or the way that v2.4 handles things that has changed.
I had posted this previously (se original post, it is clear). So why does PMFB v2.3 actually delete the plays deleted and v2.4 does not? I would also venture to guess that the PBs created prior to v2.3, but not before v2 have the same file structure. It might even be so to some degree for those prior to v2, but I remember there was some PB updater or automatic updating done by v2.x pre v2.3.
Lastly, this was NOT a problem until v2.4. My play checker didn't pick plays up in v2.3 that had been deleted in v2.2 or v2.3, only in v2.4. Had it done so I would have been talking to you about it then.
Rick
Richard K. Prescott
Rick,
without checking the old code, I don't believe 2.3 used to erase the play. First, you do note that in 2.3, you had to perform a write for evidence of the deleted play to be wiped. I know that if you add a new play, it will use a slot that is marked as NOT InUse and overwrite a previously deleted play (thereby erasing any evidence of the prior play). That behavior is the same for 2.3 and 2.4.
-Brian
While I didn't mention it, I did try the force a rewrite of a play in v2.4. It altered nothing. In fact, I just redid the entire thing using a different PB. The only way the play doesn't appear in the play listing is if after I have deleted it in v2.4 I force the play change in v2.3. Forcing the play change in v2.4 did nothing to compress or rewrite the PB.
In short, this issues is in v2.4 only.
I have the 4 resultant files if needed.
But simply do it yourself, see that what I am saying is that something in v2.4 has been changed in regards to the play deletion and PB management.
This goes beyond a security issue, it touches potential problems in the use of the PB if something happens and the play(s) gets used in a league game.
Rick
Richard K. Prescott
Rick,
I trust you. What probably happened in 2.3 that no longer happens in 2.4 is compression of the playbook at open or close. Still, the play is NOT there are far as PMFB is concerned - the program never loads that data from the disk if the InUse bit is not set. Therefore, it never shows up in the playbook to be loaded into the editor or a game. And, what I meant to say before, is this is the way Win v2.3 has always worked.
-Brian
Ugh, did I ever tell you how much I dislike the PC world?
All other issues aside, I guess I can redo that portion of my program.
But, the larger problem looms in that if the playbook gets corrupted and the "in use" bits get scrambled, well "Houston, we have a problem".
My bigger concern is that I have seen lots of plays illegal in one league, legal in another, in the same playbook. With the potential for accidentally getting used I can envision major issues for league officials. It is not simply deleted plays, but illegal deleted plays existing unchangeable unless they become undeleted.
In other words, I just don't like that from a practical standpoint.
Rick
Richard K. Prescott
Rick,
I feel your pain. Sorry to make you have to rewrite your program. You could make your program erase the "unused" plays. :) Also, I'm sure I've told you, but a new file format is just down the road, so we'll have to roll up our sleeves to deal file issues again in the coming months.
-Brian
I won't get into this at a code level - as Rick and Brian have - but I would like to note that I had a 108k playbook ...
I deleted (command-D) 20 plays.
The playbook is STILL 108k.
I COPY all the visible plays out of the playbook into a new book.
The new book is only 92k
Just an FYI. There's something still taking up space in that old playbook. Probably not worth bothering with - since the file format will be changing ...
In any case, I'll be looking forward to the new database version.