e.access writing garbage about imagebbs HOT 13 CLOSED

Uh oh. That data that's getting written into e.access is what would get written to e.idle <day>, the newly integrated "idle logging" feature. Issue #35 put a close 2 in +.lo, line 3482. Looks like e.idle <day> didn't get closed before e.access was opened. I wonder if this happens during logon.

from imagebbs.

My lines reflect the changes from issue #35 but what if i is positive and never reaches the end of 3484 to get the close statement?
The rest of 3482 would be ignored since we're using "if".

3482 ifithenx=x+11:gosub1025:x=x+16:gosub1025:close2
3484 onigoto3490:c$="e.idle "+left$(am$,1)+",s"

from imagebbs.

It happens more for each event. I was having disconnect issues, so whenever I would startup the BBS, it would get a fake connect, do it about 10 times, then finally settle down. Getting chatter from TCPser. By the end of the day, the file looked like this:

However, e.idle 2 looks interesting:

from imagebbs.

I've reviewed this and other disk errors generated from this disk image and I'm pretty sure they are being generated by a non-standard disk partitioning and file arrangement.

from imagebbs.

It's happening to e.macro now.

Incidentally, is there a way to turn off idle reporting? I've noticed it hemorrhages drive space. There will likely be those who don't have a hard drive, and will be using the VICE CBM drives, so that would be a feature request.

More technical information on this error to reproduce it, e.macro was fine while a user was logged on. The user was viewing the help menu from the main prompt, and idle-timed out forcing a disconnect. I noticed the file was rewritten as I logged on an hour later and the macros displayed the idle info.

from imagebbs.

Ick. I'm sorry about this. For now, I'd just change line 3484's on i goto 3490 to goto 3490:(rest of line). Should kill the whole feature.

(modified +.lo I'm working on:)

e.idle <day> isn't getting re-opened, and it's just writing to the currently opened file, that much is clear. I can upload an updated +.lo and +/lo.misc file to your BBS tomorrow if you want to try them out.

from imagebbs.

Ryan, whatever you've been working on for the past couple of months, please go ahead and upload it to IMW. I would like to see what you've done. Make sure to use the "Upload 2.0 Files Here" UD library for your uploads.

from imagebbs.

Okay.. Here we have another file that is getting written to, and I've closed off 3484 to match the above.

Seems the data between e.macros and e.access is getting swapped. Also, I have (on occasion) had issues with my user account (in u.config) become littered with modem idle data, even after closing that line in +.lo

from imagebbs.

Further investigation of this issue reveals that these two files (e.access and e.macro) are getting crossed. Just by sitting at the main prompt (1811) so they are not getting closed somewhere.
I was able to test this by having a hot standby of each file on a different drive, and just copying the good one over when the live file gets changed. At no time will both of the files be correct. If e.access is normal, e.macros will be hosed, and vice versa. My mods to IM have been strictly aesthetic so far, nothing that would affect file closing/opening/getting/writing. Is anyone else seeing this issue?
Try to recreate by having macros configured and enabled, then go to ST to check your stats, twice.

from imagebbs.

from imagebbs.

Using your procedures to recreate, tested for this error on IMW, WN2 and Al DeRosa's BBS. It is NOT happening on any of the tested boards.

from imagebbs.

@ThaDoctor72: is this still an issue?

from imagebbs.

from imagebbs.