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 protected]> To: Chris Idou <[email protected]> Cc: [email protected] 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 protected]) 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 [email protected]
