Re: symlinks, lstat, relative/absolute combos
Re: symlinks, lstat, relative/absolute combos
- Subject: Re: symlinks, lstat, relative/absolute combos
- From: Tilghman Lesher <email@hidden>
- Date: Tue, 22 Mar 2011 20:07:37 -0500
- Reply-by: Wed, 19 Jan 2011 16:20:00 -0600
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 <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden