Re: Bug in pathContentOfSymbolicLinkAtPath?
Re: Bug in pathContentOfSymbolicLinkAtPath?
- Subject: Re: Bug in pathContentOfSymbolicLinkAtPath?
- From: j o a r <email@hidden>
- Date: Sat, 1 Sep 2001 18:42:17 -0700
Thank you Ondra and Chris,
On Saturday, September 1, 2001, at 09:21 , Ondra Cada wrote:
joar> Could any one explain why "pathContentOfSymbolicLinkAtPath:" from
joar> NSFileManager returns "private/etc" when I feed it"/etc"?
Shouldn't it
joar> be "/private/etc/"?
It returns the _contents of the symlink_. If the contents begins
with /, the
returned value would too. Since the link in /etc contains
"private/etc", you
got that.
All right, so something like this should give me that absolute path I'm
looking for:
NSString *pathToSymLink = @"/etc";
NSString *pathFromSymLink = [[NSFileManager defaultManager]
pathContentOfSymbolicLinkAtPath: pathToSymLink];
NSString *pathToParentDir = [pathToSymLink
stringByDeletingLastPathComponent];
NSString *pathToFile = [pathToParentDir stringByAppendingPathComponent:
pathFromSymLink];
?
Would this work for all symbolic links, or just this one? Anything I
need to look out for?
Why I do this in the first place is becuase the prefered method
"stringByStandardizingPath" (using "stringByResolvingSymlinksInPath")
has this strange default behaviour:
"If the name of the receiving path begins with /private, the
stringByResolvingSymlinksInPath method strips off the /private
designator, provided the result is the name of an existing file."
This prevents me from using it to get the absolute path to files in
/etc, among other places.
(Incidentally, the trailing slash was just a typo, I hope?)
Yes, typo.
j o a r