finder file size
Hello, My apologies if this has been answered before but isn't there a simple way to get the file size as it shows under Size in Finder without using Carbon and without enumerating the directory? My understanding is NSFileSize will not do it? Thank you, Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On Tue, Apr 7, 2009 at 11:09 AM, Jo Phils wrote: > My apologies if this has been answered before but isn't there a simple way to > get the file size as it shows under Size in Finder without using Carbon and > without enumerating the directory? My understanding is NSFileSize will not > do it? Have you tried searching the archives? How about Google? See -[NSFileManager fileAttributesAtPath:traverseLink:] ... it includes a fileSize attribute. -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On 7-Apr-09, at 11:08 AM, Jo Phils wrote:
My apologies if this has been answered before but isn't there a
simple way to get the file size as it shows under Size in Finder
without using Carbon and without enumerating the directory? My
understanding is NSFileSize will not do it?
I use something like this to get the total size of the data + resource
forks for a bunch of paths. If the paths contain a large number of
files, you can run it on a separate thread so it doesn't block the UI.
- (void) totalSizeAndCountAt:(NSArray *)paths {
unsigned long long totalSize = 0, fileCount = 0;
NSFileManager *fmgr = [NSFileManager new]; // on mainThread, you can
use defaultManager
NSDirectoryEnumerator *e;
for (NSString *path in paths) {
if ([fmgr isDirAtPath:path] && ![fmgr isSymLinkAtPath:path]) {
e = [fmgr enumeratorAtPath:path];
for (NSString *subPath in e) {
totalSize += [fmgr totalSizeAtFilePath:[path
stringByAppendingPathComponent:subPath]];
fileCount++;
}
} else {
totalSize = [fmgr totalSizeAtFilePath:path];
fileCount++;
}
}
// do something with fileCount and totalSize here, e.g., notify a
delegate on the main thread to display the results
}
- (unsigned long long) totalSizeAtFilePath:(NSString *)path {
unsigned long long size = 0;
Boolean isDirectory;
FSCatalogInfo info;
FSRef ref;
OSStatus status;
OSErr err;
status = FSPathMakeRef((const unsigned char*)[path
fileSystemRepresentation], &ref, &isDirectory);
if (status == noErr) {
err = FSGetCatalogInfo(&ref, kFSCatInfoDataSizes |
kFSCatInfoRsrcSizes, &info, NULL, NULL, NULL);
if (err == noErr)
size = info.dataLogicalSize + info.rsrcLogicalSize;
}
return size;
}
Karl Moskowski
Voodoo Ergonomics Inc.
Re: finder file size
On Tue, Apr 7, 2009 at 11:09 AM, Jo Phils wrote: > Hello, > > My apologies if this has been answered before but isn't there a simple way to > get the file size as it shows under Size in Finder without using Carbon and > without enumerating the directory? My understanding is NSFileSize will not > do it? Can I ask why "without using Carbon" is a requirement? Using Carbon won't destroy your program and won't give you a strange disease. It won't even hurt your 64-bit compatibility; the only part of Carbon that went away for 64-bit is HIToolbox, the GUI bits. If it does what you want in a reasonable fashion then you ought to use it. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
Le 7 avr. 09 à 18:32, Michael Ash a écrit : On Tue, Apr 7, 2009 at 11:09 AM, Jo Phils wrote: Hello, My apologies if this has been answered before but isn't there a simple way to get the file size as it shows under Size in Finder without using Carbon and without enumerating the directory? My understanding is NSFileSize will not do it? Can I ask why "without using Carbon" is a requirement? Using Carbon won't destroy your program and won't give you a strange disease. It won't even hurt your 64-bit compatibility; the only part of Carbon that went away for 64-bit is HIToolbox, the GUI bits. If it does what you want in a reasonable fashion then you ought to use it. Probably for ecological reasons. Trying to reduce Carbon emission is the trend ;-) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
If you are worried about blocking the UI and such, I'd highly
recommend looking at FSGetCatalogInfoBulk(). You're doing a lot of
path lookups in this code (to see if you have permission to access all
components of path and such) that don't need to be done so often.
On Apr 7, 2009, at 9:09 AM, Karl Moskowski wrote:
I use something like this to get the total size of the data +
resource forks for a bunch of paths. If the paths contain a large
number of files, you can run it on a separate thread so it doesn't
block the UI.
status = FSPathMakeRef((const unsigned char*)[path
fileSystemRepresentation], &ref, &isDirectory);
if (status == noErr) {
err = FSGetCatalogInfo(&ref, kFSCatInfoDataSizes |
kFSCatInfoRsrcSizes, &info, NULL, NULL, NULL);
---
Sincerely,
Rosyna Keller
Technical Support/Carbon troll/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: finder file size
Thank you I.S. and all who replied! :-) It's my understanding that [NSFileManager fileAttributesAtPath:traverseLink:] will do fine for a single file but for directories it won't include the sizes of the subdirectories as Finder does. That's what I got in my testing as well but maybe I'm missing something? As for not using Carbon I suppose there's no reason I can't use it. I was just thinking with Finder going away from Carbon and since I'm just learning Cocoa I was trying to avoid it if I could. But if it's the best way I can use it... Thank you very much, Rick From: I. Savant To: Jo Phils Cc: cocoa dev Sent: Tuesday, April 7, 2009 11:13:19 PM Subject: Re: finder file size On Tue, Apr 7, 2009 at 11:09 AM, Jo Phils wrote: > My apologies if this has been answered before but isn't there a simple way to > get the file size as it shows under Size in Finder without using Carbon and > without enumerating the directory? My understanding is NSFileSize will not > do it? Have you tried searching the archives? How about Google? See -[NSFileManager fileAttributesAtPath:traverseLink:] ... it includes a fileSize attribute. -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
Well, directories -are- a single file so it makes sense that the file size refers to exactly the directory and not its contents. Besides, for the general case of looking at files/folders in a particular directory, you could get all the attributes quickly without paying a time penalty to recursively calculate the total file size until you decide that you actually need that information. As for choosing to use Carbon, making that decision based on what the Finder is or isn't doing is not very relevant. Not everything has been made "native" Cocoa, or a Carbon solution might be better for a particular task. If you don't want to see procedural calls in your general code, just wrap the Carbon bits in a Cocoa method wrapper and claim blissful ignorance of the implementation. :) On Apr 7, 2009, at 9:04 PM, Jo Phils wrote: Thank you I.S. and all who replied! :-) It's my understanding that [NSFileManager fileAttributesAtPath:traverseLink:] will do fine for a single file but for directories it won't include the sizes of the subdirectories as Finder does. That's what I got in my testing as well but maybe I'm missing something? As for not using Carbon I suppose there's no reason I can't use it. I was just thinking with Finder going away from Carbon and since I'm just learning Cocoa I was trying to avoid it if I could. But if it's the best way I can use it... Thank you very much, Rick From: I. Savant To: Jo Phils Cc: cocoa dev Sent: Tuesday, April 7, 2009 11:13:19 PM Subject: Re: finder file size On Tue, Apr 7, 2009 at 11:09 AM, Jo Phils wrote: My apologies if this has been answered before but isn't there a simple way to get the file size as it shows under Size in Finder without using Carbon and without enumerating the directory? My understanding is NSFileSize will not do it? Have you tried searching the archives? How about Google? See -[NSFileManager fileAttributesAtPath:traverseLink:] ... it includes a fileSize attribute. -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On 4/7/09 9:04 PM, Jo Phils said: >As for not using Carbon I suppose there's no reason I can't use it. I >was just thinking with Finder going away from Carbon and since I'm just >learning Cocoa I was trying to avoid it if I could. But if it's the >best way I can use it... Carbon is an overloaded term, it means many things all at once. Finder's Carbon->Cocoa transition refers, I think, mostly to its UI implementation. Note that the File Manager APIs (in Files.h) are not actually part of Carbon.framework, but rather part of CoreServices.framework. Those APIs are often the best way to do things. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On 8 Apr 2009, at 19:40:35, Sean McBride wrote: On 4/7/09 9:04 PM, Jo Phils said: As for not using Carbon I suppose there's no reason I can't use it. I was just thinking with Finder going away from Carbon and since I'm just learning Cocoa I was trying to avoid it if I could. But if it's the best way I can use it... Carbon is an overloaded term, it means many things all at once. Finder's Carbon->Cocoa transition refers, I think, mostly to its UI implementation. And would be the only reason people should be interested. Carbon is still extremely useful, but I understand that the UI section has been superseded by AppKit. There's nothing wrong with the non-UI part of Carbon, but I don't imagine the UI will be getting all the updates that AppKit will get, making most of it outdated. It's already started: the Carbon UI is not 64-bit, but the rest of Carbon is. It's important to understand that Carbon isn't a bad thing to use in a Cocoa app if it makes things easier. I say you should dip in to Carbon if it helps, but if there's a Cocoa way to do the same thing, that's probably preferred. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On 9 Apr 2009, at 02:03, "Sean McBride" wrote: On 4/7/09 9:04 PM, Jo Phils said: As for not using Carbon I suppose there's no reason I can't use it. I was just thinking with Finder going away from Carbon and since I'm just learning Cocoa I was trying to avoid it if I could. But if it's the best way I can use it... Carbon is an overloaded term, it means many things all at once. Yes. This has confused me a lot. I would propose to use only the term "Carbon application" as defined in: "Carbon application" ::= app whose main.c file is very big (more than 5000 characters) and contains InstallApplicationEventHandler(). as opposed to: "Cocoa application" ::= app with a very small main.m (less than 100 characters) which contains NSApplicationMain(). And NOT to use the term "Carbon" (other than in "Carbon application"), but to use the term "C-function" instead. Like: "To get the file size one can use some methods in NSFileManager, or, if one needs more detailed information (e.g. physical size, sizes of resource fork), one can use the C-functions documented in the File Manager Reference (defined in Files.h), which are part of the CoreServices.framework." To give an example of my confusion about the term "Carbon": The aforementioned "File Manager Reference" contains this sentence: "In Carbon, this name must be a leaf name; the name cannot contain a semicolon." Or: "the Carbon File Manager does not return the number of files in this field" Neither of these two sentences makes any sense for me. A somehow unrelated question: What would be a rational reason to create a new "Carbon application" today? Kind regards, Gerriet. P.S. Does anyone have a link to the official Apple definition of "Carbon application" ? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On Wed, Apr 8, 2009 at 2:40 PM, Sean McBride wrote: > Note that the File Manager APIs (in Files.h) are not actually part of > Carbon.framework, but rather part of CoreServices.framework. Except that they're part of CarbonCore.framework, which is one of the members of the umbrella CoreServices.framework. The confusion persists! --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On Apr 8, 2009, at 5:51 PM, Gerriet M. Denkmann wrote: On 9 Apr 2009, at 02:03, "Sean McBride" wrote: On 4/7/09 9:04 PM, Jo Phils said: As for not using Carbon I suppose there's no reason I can't use it. I was just thinking with Finder going away from Carbon and since I'm just learning Cocoa I was trying to avoid it if I could. But if it's the best way I can use it... Carbon is an overloaded term, it means many things all at once. Yes. This has confused me a lot. I would propose to use only the term "Carbon application" as defined in: "Carbon application" ::= app whose main.c file is very big (more than 5000 characters) and contains InstallApplicationEventHandler(). as opposed to: "Cocoa application" ::= app with a very small main.m (less than 100 characters) which contains NSApplicationMain(). And NOT to use the term "Carbon" (other than in "Carbon application"), but to use the term "C-function" instead. Like: "To get the file size one can use some methods in NSFileManager, or, if one needs more detailed information (e.g. physical size, sizes of resource fork), one can use the C-functions documented in the File Manager Reference (defined in Files.h), which are part of the CoreServices.framework." I don't know about an "official definition," but my definition of a Carbon application is one that uses either a Carbon nib or resource fork-based user interface components, i.e., legacy menu manager, control manager (or HIViews), window manager, etc., even if it uses Cocoa to perform some tasks. My definition of a "Cocoa application" is one that uses a Cocoa nib and/or user interface components based off of NSView, NSWindow, etc., even if it calls the C-based File Manager, Core Foundation, Quartz, etc., to perform some particular task. To give an example of my confusion about the term "Carbon": The aforementioned "File Manager Reference" contains this sentence: "In Carbon, this name must be a leaf name; the name cannot contain a semicolon." That is unrelated to any Carbon/Cocoa definition. File Manager path names separate path components with colons (:) instead of slashes (/). Or: "the Carbon File Manager does not return the number of files in this field" I guess this would depend on which API call and which parameter this refers to. A somehow unrelated question: What would be a rational reason to create a new "Carbon application" today? You're more comfortable working in C or C++ and your intention is that the application you create will only be used in a 32-bit environment. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
On Wed, Apr 8, 2009 at 8:51 PM, Gerriet M. Denkmann wrote: > I would propose to use only the term "Carbon application" as defined in: > > "Carbon application" ::= app whose main.c file is very big (more than 5000 > characters) and contains InstallApplicationEventHandler(). > > as opposed to: > "Cocoa application" ::= app with a very small main.m (less than 100 > characters) which contains NSApplicationMain(). I think the important distinction is what kind of event loop your application uses. If you use a Carbon event loop (RunApplicationEventLoop(), WaitNextEvent()) then you're a Carbon app. If you use a Cocoa event loop ([NSApp run], NSApplicationMain()) then you're a Cocoa app. Pretty much everything else can be mixed and matched these days, but you can only run one kind of event loop, and that in turn influences all the rest. > A somehow unrelated question: > What would be a rational reason to create a new "Carbon application" today? A couple of reasons come to mind, none of them particularly common: 1) You know Carbon vastly better than Cocoa, and your userbase is such that you don't care about the framework's impending doom, because they're never upgrading their OS X as long as they care to use your program. 2) You need your program to run on Mac OS 9. (It could happen!) At this point, Carbon-the-UI-technology pretty much just exists to allow old code to continue to work. (Incidentally, that "old code" includes a fair amount of Cocoa which is implemented on top of Carbon. Even in 64-bit.) There is little reason to start a new program from scratch using Carbon-the-UI-technology today. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
Just want to say thanks for all the input. I do appreciate it! Rick From: Benjamin Dobson To: cocoa-dev@lists.apple.com Sent: Thursday, April 9, 2009 4:01:03 AM Subject: Re: finder file size On 8 Apr 2009, at 19:40:35, Sean McBride wrote: > On 4/7/09 9:04 PM, Jo Phils said: > >> As for not using Carbon I suppose there's no reason I can't use it. I >> was just thinking with Finder going away from Carbon and since I'm just >> learning Cocoa I was trying to avoid it if I could. But if it's the >> best way I can use it... > > Carbon is an overloaded term, it means many things all at once. > Finder's Carbon->Cocoa transition refers, I think, mostly to its UI > implementation. And would be the only reason people should be interested. Carbon is still extremely useful, but I understand that the UI section has been superseded by AppKit. There's nothing wrong with the non-UI part of Carbon, but I don't imagine the UI will be getting all the updates that AppKit will get, making most of it outdated. It's already started: the Carbon UI is not 64-bit, but the rest of Carbon is. It's important to understand that Carbon isn't a bad thing to use in a Cocoa app if it makes things easier. I say you should dip in to Carbon if it helps, but if there's a Cocoa way to do the same thing, that's probably preferred. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/jo_phls%40yahoo.com This email sent to jo_p...@yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: finder file size
> Neither of these two sentences makes any sense for me. "Carbon" originally meant "the Classic Mac OS Toolbox APIs, as adapted to work on OS X". But Apple has been evolving the meaning, by rebranding those parts of the APIs that will live on in 64-bit and beyond to be "Core" APIs, while "Carbon" becomes "that which used to supported for transition to OS X but is no longer being developed." To a large extent now "Core" is lower-level stuff, and "Carbon" is UI stuff, but of course "Carbon" also contains dregs of ancient stuff that is lower-level but won't move on because it's pointless--consider parameter block routines in the File Manager for instance. -- Scott Ribe scott_r...@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
