how does history file get too large?

[bill davidsen]

In article <87oesm48qb.fsf at windlord.stanford.edu>,
Russ Allbery  <rra at stanford.edu> wrote:
| bill davidsen <davidsen at tmr.com> writes:
| > Russ Allbery  <rra at stanford.edu> wrote:
| 
| > | Yeah, I agree, we should have better error handling here.  I hope to
| > | eventually have a better history file format too; there's really no reason
| > | now for the history file to be textual, since it's actually a fixed-length
| > | field database for the most part and it's not like the entries are
| > | human-readable anyway.  That would reduce the size of the history file by
| > | about half.
| 
| > And then we could spend years writing tools to get entries back to
| > readable format
| 
| It would take me ten minutes and we get back a substantial speed gain and
| avoid most of the 2GB data problems.  The gain is definitely worth it.

So if I send you a whole bunch of tools which depend on the format of
that file and being able to seek to items in it and all such like you
are going to rewite then in ten minutes and send them back?

Or does that mean you have no tools which do that and it would take you
ten minutes to write a program which would run interminably to produce
a text flat file which is totally static? Maybe your hardware can write
a 6-7GB file in reasonable time, but mine is going to be a bit
reluctant to do that. I bet I'm not alone in using the history file as
it is.

As long as I can quickly extract all the records between two times, for
posting, arrival, and if possible expiry (haven't used that in over a year
but have used it), I can cope without reinventing every tool.
-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.