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: Sun, 10 May 2009 22:43:49 -0700 (PDT)
>> 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?
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.
>> And conversely if a path is not a directory or the kMDItemContentType == public.folder, then NSWorkspace.isFilePackageAtPath would return NO?
>
>I'm pretty sure this is true. All packages are directories, and no package type conforms to public.folder, or ever will.
-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