Why do we store the utmp/wtmp and last logs in different data
structures?
What seems strange is that they use the different data types to
store the same information (the time):
struct lastlog {
time_t ll_time;
charll_line[UT_LINESIZE];
charll_host[UT_HOSTSIZE];
};
struct utmp {
charut_line[UT_LINESIZE];
charut_name[UT_NAMESIZE];
charut_host[UT_HOSTSIZE];
longut_time;
};
Not that there is any _real_ difference between long and time_t,
but it would imagine we'd want to be as consistant as possable.
Anyhow, IMHO the umtp filestructure should be used to store the
last log. At the same time, I'm sure there is a reason for
the way things are. Could someone clue me in?
Good programmers don't waste space.
In particular, since the lastlog format uses the uid as the index into
the file, when the format was designed, the maximum file size would have
been 28 * 65536 ~= 1.8MB. By comparison, your suggestion bloats it up
to 36 * 65536 ~= 2.4MB - to add a completely useless field. Now, that
may not seem like a lot, but there was a time and day when we were
installing on 40MB hard drives and were in complete awe at how much space
we had. I remember my first serious FreeBSD box on a pair of 30MB RLL's.
This, of course, assumes the 8-character name that was in use at the time
this format was devised.
Now that we have 32-bit UID's, and 16-character names, it is a bit more
significant... although it is possible to argue that the lastlog format
itself is broken. Defining one really big uid (oh, let's say 2^32-1)
results in a 114GB-sized file, although it is likely to be sparse. :-)
This is still a problem for sparse-unaware utilities. Your approach
would yield a 180GB-sized file. I'm not sure what advantage this extra
66GB waste (that's 37% waste!) would provide.
Your point about time storage is correct, however, I believe. Using
long instead of time_t is just asking for problems. There's probably
some hysterical raison for it.
... Joe
---
Joe Greco - Systems Administrator [EMAIL PROTECTED]
Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
