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