Jens Alfke wrote:
NSLog(@"path = %@", [@"/etc" stringByStandardizingPath]); results in path = /etc when the result ought to be "/private/etc".The same thing happens with a custom symlink I created, like "/ Code", which links to "/Volumes/snoog/Code":NSLog(@"path = %@", [@"/Code/Murky" stringByStandardizingPath]); results in path = /Code/Murky
The OP said stringByResolvingSymlinksInPath does the same thing, which seems incorrect to me, if the pathname is initially valid and contains symlinks. However, if the pathname is invalid (doesn't exist, as determined by some function like stat()), then the behavior for both stringByResolvingSymlinksInPath and stringByStandardizingPath seems correct to me.
The use of stringByTrimmingCharactersInSet shouldn't be necessary if one is using valid pathnames in the first place, i.e. pathnames that are known to refer to actual file-system objects. If the original 'pat1' pathname was produced by something that knows the pathname to be valid, then trimming its whitespace is incorrect: the pathname should be used as-is.
Another possibility is a permissions restriction somewhere in trying to follow symlinks. For example, Downloads might have restricted permissions or ACL, and/or the app might not be running under the 'gerriet' uid.
If the code confirms at each step that there is a file-system object referenced by the resulting pathname, it should be easier to identify the point where things might be going wrong. If the pathname becomes invalid, then the resulting error code should identify the reason for the failure. It may be necessary to use stat() and errno in order to have sufficient information.
These are just ideas for further investigation, since we don't know the origin of the incoming 'pat1' pathname nor its original validity. A well-isolated fail-case should help clarify things.
-- GG _______________________________________________ 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
