Re: Packages vs bundles vs folders etc
Re: Packages vs bundles vs folders etc
- Subject: Re: Packages vs bundles vs folders etc
- From: Chris Idou <email@hidden>
- Date: Mon, 11 May 2009 05:11:01 -0700 (PDT)
I'm surprised that frameworks act like folders in Finder, yet don't conform to public.folder.
To be more explicit, I'm writing some code that synchronises two folders. If directory A contains file X and directory B contains file Y, then synchronising them depends on what kind of directory it is. If it is a package, then a resulting package containing files X and Y would be wrong, it could be a corrupt package. Folders should be synchronised and have both X and Y. But I'm not sure about frameworks being neither a folder nor a package. What would users expect?
Hmm, I see that bundle, package and folder are the three decendents of public.directory. framework conforms to bundle rather than package and appears in the finder like a folder. However applications descend from bundle and do NOT appear like folders.
Why does finder decide that frameworks appear like folders?
And which items does spotlight indexing delve into? Which items would iDisk synchronise atomically?
________________________________
From: Peter Ammon <email@hidden>
To: Chris Idou <email@hidden>
Cc: email@hidden
Sent: Monday, 11 May, 2009 4:02:17 PM
Subject: Re: Packages vs bundles vs folders etc
On May 10, 2009, at 10:43 PM, Chris Idou wrote:
>> Would it be fair to say that if a path is a directory, and if the kMDItemContentType != public.folder then NSWorkspace.isFilePackageAtPath would
>return YES?
>
>No. A non-package directory may not even conform to public.folder. For example, volume mount points have the type ID public.volume, which does
>conform; but frameworks have the type ID public.framework, which does not conform.
But isn't a framework a package, thus making my statement correct? If a framework is not a package, then what specifically makes a package a package that a framework doesn't fit?
Frameworks are not packages. A package is a directory that is presented as a single file to the user, but frameworks are shown as folders and are browsable like other folders.
You can check the UTI hierarchy in the UTCoreTypes.h header (try open -h UTCoreTypes.h).
Perhaps I should state my question more explicitly. I'm trying to figure out what things should be copied atomically. When a directory is really a bundle (is a bundle == package?), then it must be considered as one unit. If it's just a folder, then the files therein have their own unique reasons for existing. But I'm not sure which API exactly will give me the distinction I want to make.
If you copy two folders, Finder reports the total number of items contained within them; but if you copy two applications, Finder reports only two items. Is that the sort of distinction you want to make?
If so, I think you're on the right track. On Leopard, I would get the UTI of a file via -[NSWorkspace typeOfFile: error:], and then see if it conforms to kUTTypeFolder via -[NSWorkspace type:fileType conformsToType:(NSString *)kUTTypeFolder]. If it does NOT conform, it should be treated as a single item.
If you need Tiger compatibility, you can do the same thing, except you would use LaunchServices functions like LSCopyItemAttribute().
-Peter
_______________________________________________
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