X-Sybari-Trust:	f7728872 1864f774 39672d6f 00000138
From:	Martin Stromberg <eplmst AT epl DOT ericsson DOT se>
Message-Id:	<200212200806.JAA01947@lws256.lu.erisoft.se>
Subject:	Re: Bugs in __solve_symlinks
To:	djgpp-workers AT delorie DOT com
Date:	Fri, 20 Dec 2002 09:06:04 +0100 (MET)
In-Reply-To:	<3E02432B.EF550904@phekda.freeserve.co.uk> from "Richard Dawe" at Dec 19, 2002 10:07:39 PM
X-Mailer:	ELM [version 2.5 PL3]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Martin Str|mberg wrote:
> > 
> > According to Richard Dawe:
> > > * It doesn't cope with symlinks that point to themselves. For instance:
> > >
> > >     ln -s a a
> > >
> > > Try to stat the file 'a'. It fails with ELOOP, but it should return
> > > information about the file 'a'.
> > 
> > Are you sure?
> 
> >From the description of stat in draft D7 of the new POSIX standard by the
> Austin Group:
> 
> "If the named file is a symbolic link, the stat( ) function shall continue
> pathname resolution using the contents of the symbolic link, and shall return
> information pertaining to the resulting file if the file exists."
> 
> So if I stat 'a' above, I would expect it to resolve the symlink to 'a' and
> then return information about the symlink 'a', e.g.: the st_mode field would
> have the S_IFLNK bit set.

But if we have a -> b, b -> c, stat(a) would return information on c,
right? I. e. it follow all the symlinks in a chain. If a -> a then we
have a neverending loop.

> The left 'a' in 'a -> a' above is bright blue, to indicate that the link is
> satisfied. An equivalent test with DJGPP shows the left 'a' in black on a red
> background, indicating that the link is broken. I wonder why that is.

That might be something to correct. (stat() instead of lstat() is
used, possibly?)


Right,

						MartinS

- Raw text -