Calculating _actual_ fileSizes on disk

[Ben Rubinstein]

on 16/5/02 10:57 PM, HangTime at revolutionist at mac.com wrote:

> I assume the discrepencies are all due to the block allocation differences
> between the different sized devices.

I'm sure that's correct.

> is there some way of determining how much space a file (or series of files in
> this case) on a large storage device will actually use on a smaller storage
> device? 

Yes, but you need to access the details of the destination volume, which I
don't think you can do in Transcript.  Caveat: what follows is true for
MacOS 9 and before HFS/HFS+.  I've no idea how much of it, if any, remains
applicable in MacOS X; or how this plays on Windows.

The 'VolumeInfo' for a MacOS <=9 volume includes a value which is the
allocation block size (and another value which is the number of free
blocks).  So given a bunch of files, for each one you need to get the size
of both data and resource forks, calculate how many blocks each will take -
and there's your answer.  The allocation block size is always a multiple of
512 and for reasons that I am unclear about - but "this is how it's done" -
you actually calculate for each fork the number of 512-byte blocks that it
will take, and then calculate how many allocation blocks that many 512-byte
blocks will use.  (I can't see that this detail makes a difference - but
I've got hayfever today, so maybe I'm just dumb.  Anyway, all the code that
I've got does it that way, and it was all cut and pasted from Apple Dev
Support sample codes, so it must be right...)

The code that I'm looking at (designed to check whether a file will fit on a
destination volume) includes the caveat:

    Note: The results of this routine are not perfect. For example if the
    volume's catalog or extents overflow file grows when the new file is
    created, more allocation blocks may be needed beyond those needed for
    the file's data and resource forks.

If you're copying a large number of files, you might expect that this factor
will apply; on the other hand, it's probably only in a marginal number of
cases that it makes the difference to whether your data will fit or not.

If you're interested, I can send you the original routine (or search for
"MoreFiles" on Apple Developer CDs or on the web).  But it's basically very
simple, providing you can get access to the volume info.  There might well
be a handy XFCN lurking around somewhere - otherwise it should be a simple
one for someone to write...

The thing is, we've only recently got access in Transcript to the other bit
of data you neeed for this calculation, the size of the data and resource
forks, in "the detailed files".  The obvious thing would be to have "the
detailed volumes" which could similarly return a bunch of additional data
about volumes.  With that, this would be a simple bit of Transcript code.
 
  Ben Rubinstein               |  Email: benr_mc at cogapp.com
  Cognitive Applications Ltd   |  Phone: +44 (0)1273-821600
  http://www.cogapp.com        |  Fax  : +44 (0)1273-728866