Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu> writes:

> 
> > > stored in lots of files, e.g. the wtmp, and if you make them
> > > ridiculously long you'll waste a lot of space.
> > 
> > Especially if there are hacks fumbling with fixed length records.
> 
> given the nature of some of the files involved, using fixed length
> records may be a hack, but it's a hack which allows the files to be
> used with some semblance of efficiency.

I can think of a few trivial ways to make using variable-length
records only a *tiny* bit less efficient than the current
implementation.  For example:

If I put the record length at the end of the record, when using
last(1), I can seek back N bytes from the end of the file, read the
length, seek to the beginning of the record - N, read the length of
the previous record and the rest of the current record, etc.  This
requires one more seek and one more read to search the entire file.

When searching forward, you'd have to read ahead and parse the record
to know the length, but then you have to parse the record anyway.  You
could avoid this by stuffing another copy of the length at the
beginning, if you wanted.

If you're changing the format anyway, you could also thread the file
by userid, making `last foo' much faster.

This is not to say that any of the above ideas are good or bad, but
they *are* options.