mats@dual.UUCP (Mats Wichmann) (04/12/84)
Another cute story about large UID number happened to one of our customers once. They were also using employee numbers, and since they are a VERY large company, the numbers were four- and five-digit. This didn't really break any programs as such, but the lastlogin mechanism in Berkeley V7 has a file to keep track of the last time each user logged in. Presumably to cut down search time or something, this is done by reserving space for each possible UID. Disk space on the file system /usr/adm was residing on was real tight, and they kept running out of space. Finally, we managed to trace this down to /usr/adm/lastlog, which mysteriously grew to huge size after certain users had logged in. We would have the poor guy delete the file and reboot, and everything would be fine; then he logged in as himself, and BOOM, /usr was out of space again. The little feature reserving space for each possible user id in the lastlog file was of course not documented anywhere....but it seems, in general, to be a good idea to use user id's in the hundreds, if at all possible. Mats Wichmann Dual Systems Corp. ...{ucbvax,amd70,ihnp4,cbosgd,decwrl,fortune}!dual!mats It now became apparent (despite the lack of library paste) that something had happened to the vicar; [ Edward Gorey ]
rpw3@fortune.UUCP (04/13/84)
#R:dual:-42900:fortune:11600086:000:334 fortune!rpw3 Apr 12 18:54:00 1984 Gee... I wonder why /usr/adm/lastlog wasn't just a holey (sparse) file? You don't have to back it up, really, so various dump/restor bugs don't matter... ;-} Rob Warnock UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065