Scott Ribe wrote:
I have given up on NSWorkspace, LaunchServices and now send the path
via Distributed Objects.
Hey, that surprises me ;-) Give what you said, my next attempt would
have
been constructing an open Apple Event... (Don't know if it would work,
because I don't know when the normal resolution of symlinks & aliases
happens, but it's what I would have tried. Next up would have been
fork/exec
the open command.)
It seems to me that this is a feature that you'll need to be
proactive about
testing against new releases. Resolution of symlinks & aliases is
normally
considered a feature, ...
Except when it's considered a bug. Bug ID 2489632 is noted in Apple
sample code dating from 2003, documenting an error whereby
FSPathMakeRef silently resolves leaf symlinks. This is still extant
behavior as of 10.5.6. Anything that happens to rely on FSPathMakeRef
will of course also fail.
The recommended workaround, FWIW, is to strip off the last path
element and get the ref to the directory thus identified, then make a
new ref using FSMakeFSRefUnicode to combine the parent ref and the
leaf name into a new FSRef.
so unless it's explicitly documented that your
technique doesn't do this, you may be vulnerable to an OS update
adding a
feature and breaking your stuff...
I would disagree philosophically here. While it is likely true that
the overwhelming majority of the time someone with a symlink in hand
would want its target rather than the link itself, I would expect the
documentation to call out the fact that a routine *does* automatically
resolve leaf symlinks. That it doesn't should be the default case.
_______________________________________________
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
