Re: Not Resolving Aliases
Re: Not Resolving Aliases
- Subject: Re: Not Resolving Aliases
- From: Jean-Daniel Dupas <email@hidden>
- Date: Tue, 27 Jan 2009 12:32:17 +0100
Le 27 janv. 09 à 12:25, Jean-Daniel Dupas a écrit :
Le 27 janv. 09 à 12:03, Gregory Weston a écrit :
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.
This is no longer a bug, but a documented feature.
Sorry, I mean an undocumented feature.
If you do not want to resolve alias using FSPathMakeRef, you should
use FSPathMakeRefWithOptions passing
kFSPathMakeRefDoNotFollowLeafSymlink as option.
The recommended workaround, …
It was back in 2003, but I don't think this is the current
recommendation.
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 (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
_______________________________________________
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