X-Sybari-Trust: f7728872 1864f774 39672d6f 00000138 From: Martin Stromberg 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk > 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