On 12 May 2009, at 08:23, Jean-Daniel Dupas wrote:
Le 11 mai 09 à 23:06, Alastair Houghton a écrit :
I should explain what I meant a bit better. My point was more that
the bundle bit is HFS specific, so like the type and creator codes,
while it's good to set it, I'm not sure anything should be relying
on it.
It's more or less HFS specific. You should not care about what file
system you're using. If it it HFS, the OS will use the native
storage, if this is an FS that support ext attr, it will use ext
attr, if this is something else, it will create a ._ file, …
Or maybe I miss a not that said that FSGetCatalogInfo works only on
HFS volume ?
No, but you missed the fact that PC users will often delete ._ files
and similar, since they clutter directory listings. You might also
conceivably lose the bundle bit through the use of some archiving tool
that was written for UNIX-like systems but that doesn't have the
necessary support for OS X. Or by using tools that *do* know about OS
X, but then extracting an archive on another platform (to a network
filesystem, for instance).
As for the "you should not care about what file system you're using",
that's a bit sweeping. For a "normal" app, it's probably true, but
there are plenty of cases where you genuinely *do* need to know things
about the filesystem. Additionally, Carbon (e.g. FSGetCatalogInfo())
isn't the only way to read the bundle bit, but non-Carbon APIs don't
have the emulation support you mention.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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]
