Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!sys.uea!jrk
From: jrk@sys.uea.ac.uk (Richard Kennaway)
Newsgroups: comp.sys.mac.programmer
Subject: Missing megabytes
Message-ID: <457@sys.uea.ac.uk>
Date: 7 Mar 89 11:06:12 GMT
Reply-To: jrk@s1.UUCP (Richard Kennaway)
Organization: University of East Anglia, Norwich
Lines: 36

I am writing a program which, among other things, makes a directory
listing of a volume.  There is a strange discrepancy in the
information it collects.

Using PBHGetVInfo, it determines the number of files and folders on the
volume, the number of blocks, and the number of free blocks.  The
difference between the last two figures should be the number of used
blocks.

When it scans through all the files and folders with PBHGetCatInfo
in the usual way, it always finds exactly the right number of files and
folders, but the sum of their sizes is sometimes less than the
calculated number of used blocks.  Some typical figures (numbers of blocks):

				disk1	disk2	disk3
			
    ioVNmAlBlks - ioVFrBlk	38600	41600	43758
    total size of all files	36908	41600	43459

It calculates the size of a file by rounding both the ioFlPyLen and
ioFlRPyLen components of the PBHGetCatInfo parameter block up to a
multiple of the block size (ioVAlBlkSiz in the block returned by
PBHGetVInfo), dividing by the block size, and adding the two figures.

Am I missing something?  Disk1 and disk2 above are of identical
manufacture (40Mb Qisk).  If there is internal housekeeping
information that occupies allocation blocks but doesnt belong to any
file, why does it occupy 1.7 megs on disk1 and nothing on disc2?
Disk3 is the internal disc of a MacII.

Inspection of the directory listings showed nothing strange.  In all
cases, the listing was made to a file on a volume other than the one
being scanned.
-- 
Richard Kennaway                SYS, University of East Anglia, Norwich, U.K.
uucp:	...mcvax!ukc!uea-sys!jrk	Janet:	kennaway@uk.ac.uea.sys