Re: Symbolic Links in Snow Leopard
Re: Symbolic Links in Snow Leopard
- Subject: Re: Symbolic Links in Snow Leopard
- From: Greg Guerin <email@hidden>
- Date: Sun, 6 Sep 2009 16:51:06 -0700
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 (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