search

Pinacolada64 / ImageBBS

A bulletin board system (BBS) for the Commodore 64.
15 stars 5 forks source link

e.access writing garbage #42

Closed ThaDoctor72 closed 5 years ago

ThaDoctor72 commented 6 years ago

Not sure what is causing it, but e.access seems to constantly add lines to the file until eventually it is completely overwritten.

image

Pinacolada64 commented 6 years ago

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.

ThaDoctor72 commented 6 years ago

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"

ThaDoctor72 commented 6 years ago

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: image

However, e.idle 2 looks interesting: image

x-tec2017 commented 6 years ago

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.

ThaDoctor72 commented 6 years ago

It's happening to e.macro now. image

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.

Pinacolada64 commented 6 years ago

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:) https://github.com/Pinacolada64/ImageBBS/blob/0865d16c003d6cfd5820f75a4072ffd9751ad9a7/v2/core/plus_lo.lbl#L454

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.

x-tec2017 commented 6 years ago

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.

ThaDoctor72 commented 6 years ago

Okay.. Here we have another file that is getting written to, and I've closed off 3484 to match the above. image 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

ThaDoctor72 commented 6 years ago

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.

Pinacolada64 commented 6 years ago

I haven't set up e.macros yet. I will try later this weekend.

On Fri, Nov 9, 2018 at 9:07 AM Hoy Brothers notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Pinacolada64/ImageBBS/issues/42#issuecomment-437426797, or mute the thread https://github.com/notifications/unsubscribe-auth/AHKHxJB5_6xwviPZP8ZGz2UZCHe4wrL_ks5utbZrgaJpZM4Xy0_3 .

--

x-tec2017 commented 6 years ago

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.

Pinacolada64 commented 5 years ago

@ThaDoctor72: is this still an issue?

ThaDoctor72 commented 5 years ago

No.

On Wed, Mar 20, 2019, 3:53 PM Ryan Sherwood notifications@github.com wrote:

@ThaDoctor72 https://github.com/ThaDoctor72: is this still an issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Pinacolada64/ImageBBS/issues/42#issuecomment-475002531, or mute the thread https://github.com/notifications/unsubscribe-auth/Ao7IS71SIyMBda8THxu678ZlgfkXqlGPks5vYpGpgaJpZM4Xy0_3 .