Date: Tue, 14 Jan 1997 17:00:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: proff@suburbia.net Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: truss, trace ?? Message-ID: <199701150000.RAA02388@phaeton.artisoft.com> In-Reply-To: <19970114234038.5396.qmail@suburbia.net> from "proff@suburbia.net" at Jan 15, 97 10:40:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > "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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701150000.RAA02388>