open https://gitlab.synchro.net/main/sbbs/-/issues/1085

If your `logs/error.log` file is 419MB, and you use `;ERR` and press `END` the "Seeking" seems to take a minute or two.

Also, I apparently only had one error in the enture 419MB file which apparently doesn't rotate.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1085#note_8460

The `data/error.log` file rotates per the configured policy in SCFG->System->Advanced->Maximum Log File Size.

The P_SEEK "end" key does read every line so that it can know the number of lines (and starting offset of each). There's probably a more elegant solution.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1085#note_8461

Generally, I don't rotate by size, I rotate by date and that's coordinated with my backup schedule.

error.log is a bit of a weird case because it seems as though it's entirely a duplicate of my existing logs, but there's no way to suppress it.

I often forget about it completely until I get an error notice logging in and when I go to view the log with "1 error", it ends up being 419MB. :grinning:
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1085#note_8463

Yeah, looking at the code, building the index of all the line offsets using a ever-growing realloc() may be the big slowdown, rather than reading every line. Likely cutting down on the realloc() calls would help a lot.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)