Determining "on disk" file size

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Tom Harrington - 23 Sep 2004 21:02 GMT

If I have a file that's 900 bytes long on an HFS+ disk, the Finder
indicates 4KB on disk. Move it to UFS and it indicates 1KB on disk.

However various API calls I've tried all return 900 in this case.
Presumably if I want the larger Finder-indicated numbers, I need to get
information on the file system, and round up. Can anyone suggest the
API I'd need to do this?

Signature

Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/

Reply to this Message

Miro Jurisic - 23 Sep 2004 22:01 GMT

> If I have a file that's 900 bytes long on an HFS+ disk, the Finder
> indicates 4KB on disk. Move it to UFS and it indicates 1KB on disk.
[quoted text clipped - 3 lines]
> information on the file system, and round up. Can anyone suggest the
> API I'd need to do this?

Call FSGetCatalogInfo and add dataPhysicalSize to rsrcPhysicalSize.

hth

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

Mike Hall - 26 Sep 2004 06:32 GMT

>> If I have a file that's 900 bytes long on an HFS+ disk, the Finder
>> indicates 4KB on disk. Move it to UFS and it indicates 1KB on disk.
[quoted text clipped - 3 lines]
>> information on the file system, and round up. Can anyone suggest the
>> API I'd need to do this?

>Call FSGetCatalogInfo and add dataPhysicalSize to rsrcPhysicalSize.

Or, from the UNIX/POSIX side, use the 'stat()' system call,
where several fields will help you:

off_t st_size; /* file size, in bytes */
quad_t st_blocks; /* blocks allocated for file */
u_long st_blksize;/* optimal file sys I/O ops blocksize */

Reply to this Message

Miro Jurisic - 26 Sep 2004 08:57 GMT

> >Call FSGetCatalogInfo and add dataPhysicalSize to rsrcPhysicalSize.
>
> Or, from the UNIX/POSIX side, use the 'stat()' system call,
> where several fields will help you:

Will that include the resource fork blocks?

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

Tom Harrington - 26 Sep 2004 23:23 GMT

> > >Call FSGetCatalogInfo and add dataPhysicalSize to rsrcPhysicalSize.

Thanks, I appreciate it, although since my experience is more Unix than
Carbon, I prefer:

> > Or, from the UNIX/POSIX side, use the 'stat()' system call,
> > where several fields will help you:

Thanks, that has the added benefit that I can do it from Perl if I need
to.

> Will that include the resource fork blocks?

Of course not, but knowing this, it's a simple matter to wrap a function
that stat()s both the path, and the path with "/..namedfork/rsrc"
appended, and returns the sum.

Signature

Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/

Reply to this Message

Miro Jurisic - 26 Sep 2004 23:52 GMT

> Of course not, but knowing this, it's a simple matter to wrap a function
> that stat()s both the path, and the path with "/..namedfork/rsrc"
> appended, and returns the sum.

FWIW, I am sure that calling stat twice is slower than calling FSGetCatalogInfo
once, but it's possible you don't care. Don't forget to use Unicode-savvy
functions for your path manipulations.

meeroh

Signature

If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Reply to this Message

Eric Albert - 27 Sep 2004 00:36 GMT

> > Of course not, but knowing this, it's a simple matter to wrap a function
> > that stat()s both the path, and the path with "/..namedfork/rsrc"
[quoted text clipped - 4 lines]
> once, but it's possible you don't care. Don't forget to use Unicode-savvy
> functions for your path manipulations.

If you're starting with a path and not with an FSRef, I'd expect the two
stats to be faster than constructing an FSRef and calling
FSGetCatalogInfo.

-Eric

Signature

Eric Albert ejalbert@cs.stanford.edu
http://outofcheese.org/

Reply to this Message

Tom Harrington - 27 Sep 2004 04:23 GMT

> > > Of course not, but knowing this, it's a simple matter to wrap a function
> > > that stat()s both the path, and the path with "/..namedfork/rsrc"
[quoted text clipped - 4 lines]
> > once, but it's possible you don't care. Don't forget to use Unicode-savvy
> > functions for your path manipulations.

Well, although I didn't mention it initially, the "I can also use stat()
in Perl" angle is more important than questions of speed in this case.

> If you're starting with a path and not with an FSRef, I'd expect the two
> stats to be faster than constructing an FSRef and calling
> FSGetCatalogInfo.

I would be starting with a path, regardless of whether I was using Perl
or C.

Signature

Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/

Reply to this Message

Mac Forum / Programming / Mac Programming / September 2004

Determining "on disk" file size