Re: Get size of folder
Re: Get size of folder
- Subject: Re: Get size of folder
- From: Bill Monk <email@hidden>
- Date: Wed, 19 Aug 2009 12:14:05 -0500
- Resent-date: Wed, 19 Aug 2009 12:17:25 -0500
- Resent-from: Bill Monk <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
PCWiz wrote:
The next thing I tried was using the Carbon File Manager API
using this method by Dave DeLong:
http://github.com/davedelong/BuildCleaner/blob/b2712242b4eea1fff0e78a08b393a417e3019c8a/NSFileManager+FileSize.m
This method worked for some folders/files, but for others it returned
wildly innacurate numbers
That code won't work for your purposes. It ignores the size of
resource forks. And its crux
// add the size for this item
totalSize +=
fetchedInfos[thisIndex].dataLogicalSize;
counts only the *logical* file size. Recall that even a 1-character
file still uses a full physical allocation block on disk, and the
allocation block size varies depending upon device capacity,
partitioning scheme, etc.
To replicate Finder's displayed file sizes, you need the *physical* on-
disk sizes of all forks in a file, not their logical sizes. That's
irrelevant.
The method I'm using right now is probably the closest I've ever
gotten:
No need to reinvent this wheel. Pass an FSRef to your directory of
interest (or even the disk's root directory) to
OSErr FSIterateForks (
const FSRef *ref,
CatPositionRec *forkIterator,
HFSUniStr255 *forkName,
SInt64 *forkSize,
UInt64 *forkPhysicalSize
);
and loop, adding up everything it returns in its last parameter. Or
use FSGetCatalogInfo et. al. just be sure to use the physical fork
sizes. Though note that FSIterateForks saves dealing with the (highly
unlikely at this point, but still) possibility of files with named
forks that aren't the data fork -or- the resource fork!
The folder size method rounds up the files to the 4KB minimum block
size.
Unwarranted assumption. Sure, it may be 4kB on your HFS+ volume, but
it can be very different on other file systems, optical media, FAT32,
etcetcetc. HFS (non "+" HFS) volumes, being limited to 65536
allocation blocks, have minimum block sizes that increase with
partition size. Even a 1GB volume has a minimum physical file size of
16K, and it just gets worse from there. 4K, that's an HFS+ feature.
Don't go down this road. You'll make yourself crazy.
fsize = [fattrs objectForKey:NSFileSize];
Again, useless for your purposes. NSFileSize is documented not to
report resource fork sizes. And its docs are vague on whether by "the
file's size in bytes" it means physical or logical. You can experiment
to find out, but still, wrong tool for the job.
Really, this problem was solved long ago, and pretty optimally. Sure,
it *might* be possible to do better than the File Manager engineers,
but is anyone prepared to argue it's not a *very* premature
optimization?
One could do much worse than to look at FSGetTotalForkSizes() in
MoreFilesX* as an example of how to use FSIterateForks():
http://developer.apple.com/samplecode/MoreFilesX/index.html#//
apple_ref/doc/uid/DTS10000474
*for some reason that page is marked "deprecated", though it was
updated as recently as 2005. I see no reason why FSGetTotalForkSizes,
at least, is not fine. It's very simple, doesn't use deprecated API,
and certainly it works fine in shipping code for me.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden