Deleting members has nothing to do with getting rid of bad data with the attachments log or bad data in message files.  (And the errors in Maintenance and Attachments deal with bad data in those other places.)

(And the problem in Display is also an attachment issue. Although why that one triggered for you and not for me is a mystery.)
For Display add

        $mfn ||= q{}; 

just above the

         chomp $mfn; 

on line 1005.

Edited:

In Attachments.pm find

    foreach (@attachments) {
         my $space = ( split /[|]/xsm, $_ )[5];
         $attachment_space += $space;
         $attachment_space = number_format($attachment_space);
     } 

replace with

    foreach my $i (0 .. $#attachments) {
         my @check = split /[|]/xsm, $attachments[$i];
         if (scalar @check != 9) {
             fatal_error( 'bad data', "attachments.db bad line $i", 1 );
         }
         my $space = $check[5];
         if ($space =~ /\D/xsm || $space eq q{} ) {
             fatal_error( 'bad data', "attachments.db line $i", 1 );
         }
         $attachment_space += $space;
         $attachment_space = number_format($attachment_space);
     }

  

Like the new check in Maintenance, this one checks to make sure the field it's looking for has only numbers in it. If not, it throws an error telling you what line the problem is on in attachments.db (You already know what file you need to look in.)

I should probably add a check to make sure each line in attachments.db is exactly 9 fields long. 

Edited:

pyragony54 wrote on Sep 8^th, 2017 at 5:06am:



The error I could fix, it was only a bad contribution from member toskana102.

Okay, in Display.pm find

                    $attach_count{$atfile} = $atcount; 

and add above it

                    $atcount ||= 0; 

This will force the download count to be 0 if there's no number. I think if you look at the raw data in attachments.db, you may find most of the lines in your file end with | instead of | and a number.

You may have to open your attachments.db in a spreadsheet  - replace all the | with a tab (\t) so you'll be able to manipulate the data (or zip up the old txt file and the new .db file and sent them to me so I can run a comparison in a spreadsheet - but there is definitely something off with those files and it seems to be getting worse.

Also, if your Convert2x created a Variables/datacheck.txt file - zip that up and send it along.

So I'm also a little idiot. If I had first in the mainforum the maintenance mode go through and then only the necessary files from the main forum to the test forum, everything would have looked better and many errors would not show up.

Two errors still appear, but my opinion is not the software.
I am now looking at what I still find there with the help of your debugger.
What I noticed, however, in some rubrics was not sorted by "last post", although I have set it so. Can you look in the test forum.

pyragony54 wrote on Sep 9^th, 2017 at 9:38am:


$boardv can legitimately be blank - but I don't why your system is throwing a hissy and mine doesn't. The error clears up because the Variables/user.log gets rewritten everytime someone enters the forum or looks at something.

In BoardIndex find

        foreach (@logentries) {
             ( $name, $date1, $last_ip, $last_host, undef, $boardv, undef ) =
               split /[|]/xsm, $_, 7;  

Add after

$boardv ||= q{}; 

Quote:


This is going to be due to bad data in forum.master. There's a board in there that doesn't have data in the first field. (look for '$board{'admin'}' as that shouldn't be there in 2.7 But I also just noticed that data didn't transfer for admin/admin_fix into forum.control  )

as a fix try:
In Load.pm find

                    my $boardname = ${$board{$i}}[0];
                     $mybrds .= qq~$boardname<br />~;
                     return 1; 

replace with

                    if (${$board{$i}}[0]) {
                         my $boardname = ${$board{$i}}[0];
                         $mybrds .= qq~$boardname<br />~;
                         return 1;
                     } 

All of these, so far, have nothing to do with Mods. For whatever reason, your install is more sensitive to uninitialized values than mine - maybe it's a Perl difference or a Perl on Windows difference. But it isn't a bad thing. As I said before: old YaBB ignored a lot of things that should have thrown errors. 2.7 throws the errors.

But once I see where the error message is pointing to I can see exactly what's happening and why.

I also find it class, the YaBB 2.7 does not ignore the error.
My server is running Debian, not Windows. I'm not stupid.
Windows Server and you have already lost.
The two error messages are gone.
The only downside, some forums are not sorted by last post.
Look here:

http://yabbtest.de/cgi-bin/yabb2/YaBB.pl?board=LKV

You have there also admin rights, so you can see it.

pyragony54 wrote on Sep 9^th, 2017 at 3:02pm:


That's weird since the same Board sorts just fine in my test install.  (in WAMPP)
Edited: