Summary: According to the documentation for -[NSString stringByResolvingSymlinksInPath] at http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/doc/uid/20000154-stringByResolvingSymlinksInPath "If the original path is absolute, all symbolic links are guaranteed to be removed". A method that did this would be awesome. However, stringByResolvingSymlinksInPath is not awesome: it breaks the guarantee. Thus, I'm wary of ever using this method, because it can't be trusted. Steps to Reproduce: [@"/etc/aliases" stringByResolvingSymlinksInPath] Expected Results: @"/private/etc/postfix/aliases" Actual Results: @"/etc/postfix/aliases" Regression: This occurs with both Mac OS X 10.5.4 and 10.4.11. In both OS versions, /etc is a symbolic link to /private/etc, and /private/etc/aliases is a symbolic link to /private/etc/postfix/aliases. Notes: According to the discussion in the documentation, "If the name of the receiving path begins with /private, the stringByResolvingSymlinksInPath method strips off the /private designator". However, in my example the receiving path @"/etc/aliases" begins with /etc, not with /private. Furthermore, this documented behavior also breaks the guarantee of removing symbolic links; on the contrary, it adds a symbolic link. Thus, the method's documentation seems to contradict itself. What I want is a method that resolves all symbolic links, period. No exceptions.