site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meg.abyt.es; s=google; h=domainkey-signature:from:to:subject:date:user-agent:references :in-reply-to:reply-by:x-message:mime-version:content-type :content-transfer-encoding:message-id; bh=lxBrVoqzDkBN1h1W17vPK8k9hAzmR7BfX1ucZ/Vhb+E=; b=SVq66xEuX7vy7xu3O99tSBgmB16jmyb8a9svk3YAM5u8ZzwFB9NNDpRk3V6lrd6lsI XpG9iFt6MZ1DIcHYaQ75cPOKtiy817NuEIYwU0UKvYW37qGEModk5NzHDGp7gi9bVI50 bKKkkUOfwct2NIwFA083EpmSjyCkM9RtqhDsc= Domainkey-signature: a=rsa-sha1; c=nofws; d=meg.abyt.es; s=google; h=from:to:subject:date:user-agent:references:in-reply-to:reply-by :x-message:mime-version:content-type:content-transfer-encoding :message-id; b=kEy7vptN1rCLPDJL/EYgdYiCFSN1AJYFlkY1VpT900gfzZtq3kjvXUUnR2fwxZVL6J mX1rZCwIzoa1gaI0MQn+fs0vUpw0QIjjxMEFcDvkUaO5UFX5tcsoyc1bWzmLHYwMpIgt D4Qt7QQj6oprdaT5y+37xL2MUd0lYbb7A+NwA= Reply-by: Wed, 19 Jan 2011 16:20:00 -0600 User-agent: KMail/1.13.5 (Linux/2.6.32-30-server; KDE/4.4.5; x86_64; ; ) On Tuesday 22 March 2011 18:17:16 you wrote:

On Mar 22, 2011, at 3:02 PM, Tilghman Lesher wrote:

...

On Tuesday 22 March 2011 13:25:40 Steven Abner wrote:

...

On Mar 22, 2011, at 2:18 PM, Tilghman Lesher wrote:

...

On Tuesday 22 March 2011 13:03:15 James Peach wrote:

...

On 22 March 2011 06:08, Steven Abner <pheonix@zoomtown.com> wrote:

...

Hi ,

I was working on Mac symlinks(unix style) and encountered things I

couldn't find information on through web searches. I was thinking these are Mac specific flags and meanings, so with that intro: when you lstat() a symlink, lstat states that st_size will be the size of the pathname for the link, what does it mean when it is a link with st_size = 0, yet it does have a link?

I believe that the st_size of a symlink is a filesystem implementation detail. You should not rely on it for anything serious.

That may be, but it's still in POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/lstat.html

I just verified on my own system that it is working correctly for an HFS+ filesystem. The OP may wish to verify his own code is working correctly by comparing his output to that of 'stat -x {file}'

I had only found one instance so far where the Mac returned st_size = 0. I didn't wish to assume anything! The case was in testing "/dev/stdin" which has relative link to "fd/0".

Yep, probably need to report that to the Darwin team as a bug. Just verified that it reports correctly on both FreeBSD and Linux. If you don't, I will, but the report needs to be clear that the determining specification is POSIX, and this is needed for POSIX compliance.

Could you please report. I had hard time writing to you all for fear of head bitten off. And if you could there are a couple of broken links, "/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libLTO.dylib", "/Developer/SDKs/MacOSX10.6.sdk/usr/lib/python2.5" and "/Developer/SDKs/MacOSX10.6.sdk/usr/lib/python2.6"

Yeah, there are lots more such examples, unfortunately.

Thanks loads, I now know its not mac specific flag, just wish the "//////" wasn't a standard.

Sounds like you're reimplementing realpath(3). Mac OS X has the (safe) behavior of being able to pass NULL as the second argument to realpath() and having the resolved path allocated by malloc(3). You'll need to ensure that you free(3) the return value afterwards, but it will probably make your life a whole lot easier to use it. Just be careful with it, if your application needs to be portable. Not all systems allow the second argument to be NULL; those systems have a possible buffer overflow exploit vector, should you use realpath(3). -- Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com