Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: wtmp problem: garbage in /usr/adm/wtmp
Message-ID: <6554@mimsy.UUCP>
Date: Tue, 5-May-87 02:23:46 EDT
Article-I.D.: mimsy.6554
Posted: Tue May  5 02:23:46 1987
Date-Received: Wed, 6-May-87 01:02:57 EDT
References: <469@uhccux.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 18
Summary: File system full

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.

(If O_APPEND mode is not broken, no write will be split across
two blocks by any I/O wait, as the inode is locked across each
call to bmap [/sys/sys/sys_inode.c$ino_rw()].)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris