Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix
Subject: Re: Relational Database Responses
Message-ID: <446@rlgvax.UUCP>
Date: Sat, 9-Feb-85 12:56:27 EST
Article-I.D.: rlgvax.446
Posted: Sat Feb  9 12:56:27 1985
Date-Received: Mon, 11-Feb-85 04:46:46 EST
References: <8138@brl-tgr.ARPA>
Organization: CCI Office Systems Group, Reston, VA
Lines: 20

> 13. When doing a file system check(fsck) on the onyx "Possible file size
>     error "  shows up on system containing the unify dbms.

This ain't a bug in UNIFY; it's arguably a bug in "fsck".  This error
message is printed if the number of blocks implied by the file size
doesn't match the actual number of blocks allocated to the file.
Unfortunately, if the file has "holes" (i.e., sections in the middle of the
file with no blocks allocated to it), these numbers won't agree.
"Holes" are a well-known - and even documented - feature (deliberate
feature - sparse files can save lots of disk space) of UNIX ever since
V6 (although they didn't work as well in V6 as in post-V6 systems - reading
a "hole" in V6 caused the blocks to be allocated).

I suspect the "correct" answer is to compare the number of blocks implied
by the file size with the number of blocks implied by the block number
of the highest allocated block (i.e., if the file had no holes, this would
be the number of blocks in the file).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy