• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Not Resolving Aliases
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Not Resolving Aliases


  • Subject: Re: Not Resolving Aliases
  • From: Gregory Weston <email@hidden>
  • Date: Tue, 27 Jan 2009 06:03:40 -0500

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 (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


  • Follow-Ups:
    • Re: Not Resolving Aliases
      • From: Scott Ribe <email@hidden>
    • Re: Not Resolving Aliases
      • From: Jean-Daniel Dupas <email@hidden>
  • Prev by Date: Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
  • Next by Date: Re: Not Resolving Aliases
  • Previous by thread: Re: Not Resolving Aliases
  • Next by thread: Re: Not Resolving Aliases
  • Index(es):
    • Date
    • Thread