Re: [MacPerl] Getting size of resource forks

[jwb@olympus.net (John W. Baxter)]

>>
>> At 13:36 4/28/96, Bill Middleton wrote:
>> >If you can use the new PowerTools extensions, try something like
>> >this:
>
>[...]
>> >
>> >Hopefully faster than asking the finder.
>>
>> And produces a smaller number in any file whose resource fork hasn't been
>> compacted <and smaller by the per file, per type and per resource overhead
>> and the sizes of the names of the named resources, probably, too>.  Which
>> number is wanted (bytes in resource fork vs total bytes in the active
>> resources data) is unclear, but more likely it's the former, which the
>> excellent script above doesn't produce.  Aside from the holes, the
>> overheads are computable, but it hardly seems reasonable to do so.
>
>The above is a bit unclear, would you care to reword for those of us who are
>interested?
>
>Indeed, the ask-finder script seems to return a slightly larger number.
>
>GetResourceSizeOnDisk() supposedly returns the exact size of the resource
>as it exists on the disk, not in memory.  From the standpoint of the
>original question, this seems, imho, more appropriate.

The resource file has some fixed overhead (256 bytes), some per resource
type overhead, some per resource overhead, and the names of the named
resources (also overhead).  Simply adding up the sizes of the resources
will miss those overheads.  I forget whether there are small (0 to three
byte) gaps between resources for alignment purposes, or not.

Further, when a resource is deleted from a resource file, the freed up
space is not normally removed...it remains as space being used (for nothing
useful) in the resource file.  There's a call which does remove the
space...the Mac culture says it's slow:  it is a little slow, but the
culture is remembering resource files on diskette, where it was really slow
and therefore avoided.

So again, there are two possibly-interesting numbers:  the number of bytes
the whole resource fork occupies on disk, and the smaller (by either just
the overheads or by the overheads plus the removed resources) sum of the
sizes of each resource.  Note that a summation routine could be written to
account for the overheads...accounting for the unused space is much
trickier (possible, of course).

   --John

  --
   Each day is a gift.  That's why we call today "the present."
jwbaxter@olympus.net (John W. Baxter)  Port Ludlow, WA, USA