Subject: Re: misc/2668: login-names >8 chars make no fun
To: matthew green <>
From: Chris G Demetriou <>
List: current-users
Date: 08/15/1996 21:49:40
>    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.


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

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.