Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!lsuc!dave
From: dave@lsuc.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: wtmp problem: garbage in /usr/adm/wtmp
Message-ID: <1775@lsuc.UUCP>
Date: Wed, 6-May-87 12:01:19 EDT
Article-I.D.: lsuc.1775
Posted: Wed May  6 12:01:19 1987
Date-Received: Thu, 7-May-87 06:23:42 EDT
References: <469@uhccux.UUCP> <6554@mimsy.UUCP>
Reply-To: dave@lsuc.UUCP (David Sherman)
Organization: Law Society of Upper Canada, Toronto
Lines: 32
Summary: it can be patched up with dd(1)

In article <6554@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <469@uhccux.UUCP> todd@uhccux.UUCP (The Perplexed Wiz) writes:
>>... my wtmp file was getting data ok and then it looks like some
>>garbage got thrown into it causing an extra field to be inserted
>>between the last "good" structure field and the next entry into wtmp.
>
>This occurs when the file system fills up.  `struct utmp' is 36
>bytes long in stock 4.3BSD.  It was 20 bytes long in 4.1BSD, and
>may have been 28 bytes in 4.2BSD.  None of these are even divisors
>of any file system block size, so when the system runs out of
>blocks, a write may succeed partially, leaving a bit of a utmp
>entry behind to confuse things.

Exactly. We've had that happen a few times on our v7-based system
(wtmp record size = 20), so I keep this little script around to
fix it:
	dd if=wtmp bs=20 count=3993 of=wtmp.new1
	dd if=wtmp bs=1 skip=79872 of=wtmp.new2
following, after checking the results, by "cat wtmp.new[12] > wtmp".

Obviously, you have to find the correct numbers for this. An
interactive binary search works fine. Run things like
	dd if=wtmp bs=20 skip=3000 of=junk; who junk | more
and jump back and forth (or examine the output of "who junk")
until you narrow it down to the exact record gone awry. A little arithmetic
will then give you the numbers to plug in.

David Sherman
The Law Society of Upper Canada
Toronto
-- 
{ seismo!mnetor  cbosgd!utgpu  watmath  decvax!utcsri  ihnp4!utzoo } !lsuc!dave