From owner-freebsd-hackers Tue Jan 14 16:13:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA18308 for hackers-outgoing; Tue, 14 Jan 1997 16:13:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA18303 for ; Tue, 14 Jan 1997 16:13:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA02388; Tue, 14 Jan 1997 17:00:14 -0700 From: Terry Lambert Message-Id: <199701150000.RAA02388@phaeton.artisoft.com> Subject: Re: truss, trace ?? To: proff@suburbia.net Date: Tue, 14 Jan 1997 17:00:14 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <19970114234038.5396.qmail@suburbia.net> from "proff@suburbia.net" at Jan 15, 97 10:40:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > "Natural" for text files, maybe. > > > > For the wtmp file, it's not so natural... it's wierd, even, since you > > can't resync to a valid record boundry without sync data built into > > the data format. > > > > For text files, the sync data can be "after the first \n", since it > > is a variable length record format with "\n" record seperators, but > > how do you resync wtmp? > > It's quite easy actually. There are two ways: > > (a) always truncate by the size of the last write. > (b) define the cycle period to be a multiple of > the record size. This will work if the record size does not vary. There have been rumblings of versioning the wtmp structure definition, so that it *can* vary within the same file. You *could* deal with this if you made a file specific "truncator" function, but probably not otherwise. This also assumes that you are truncating on character, not block boundries, or that the structures are some even log2 of the block size (if you truncate on block boundries). Having a file specific truncator that just shifted records down in the file, on record boundries, would undoubtedly work, but you would need NULLFS working for you to derive a layer so that you could hide it happening, at the user level. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.