Mail Archives: cygwin/2007/06/26/12:43:20
Matthew Woehlke <mw_triad <at> users.sourceforge.net> writes:
> >> "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."
> >
> > This says nothing about what is returned if the file does not exist.
>
> RETURN VALUE
> Upon successful completion, 0 shall be returned. Otherwise, -1 shall
> be returned and errno set to indicate the error.
Matthew is right. And if that isn't enough to convince you, you should also
read POSIX XBD 4.11, which talks all about pathname resolution.
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html
Since stat() is not one of the special functions that operates on symlinks, it
MUST resolve whatever the link points to, and if the link is broken, then it
must behave the same way it does for any other resolution failure, ie. in this
case, fail with ENOENT. In short, it is IMPOSSIBLE for stat() to give you a
struct stat that passes S_IFLNK on a compliant platform. Give up your argument
now. There are enough of us on this list that know POSIX and SUSv3 that you
will not win.
And yes, we are aware of the POSIX-compliance bug where cygwin currently does
not always correctly resolve pathnames such as "foo/..".
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -