>    Either you change the binary format of utmp and wtmp, or you don't.
>    
>    If you don't, you aren't recording all of the login name.
>    If you do, you break binary compatibility.
> 
> except if you take the idea that SVR4 used (creating another file,
> with much larger username/hostname/etc, but still fixed size
> entries, and then having the routines to update this file also
> maintain the utmp/wtmp files) and learn from their mistakes and
> come up with a *real* solution, that just happens to also maintain
> backwards compatibility.

Huh?!

As in: have, say, another file which contains user names, and have
utmp/wtmp point to entries in the second file?

It seems that that's slow, unnecessarily complicated, and unless done
carefully can be prone to not keeping accurate track of the
information.

Re: the latter:  For instance, say on day 1 i have user bob with uid
1000.  bob logs in, logs out.  day 2: i delete bob's account.  day 3:
i add a new account, joe, with UID 1000.  either the second (database)
file is ever-increasing in size (and no entries are re-used), or it's
indexed by a bogus index (e.g. the UID), which can yeild the wrong
results in the case given above.  Given that these files are e.g. used
for system accounting, that's a bad situation to be in.  Right now,
it's not a problem, since the user name is stored...  (yeah, if you
have a new user with the same name as an old, removed, user, you'll
have a problem, but you could either way.)


> you could also "break" binary compatibility but retain the ability
> to read the old format with updated tools that do both.

That's relatively difficult, since the files and/or records in
question have no magic number by which you can determine their
versions.  Sure, you could use a heuristic, but it's quite likely that
it wouldn't always work.



cgd