On Tue, May 08, 2007 at 11:08:35 +0200, Alex Riesen wrote:
> On 5/8/07, Liu Yubao <yubao.liu@xxxxxxxxx> wrote:
> >+#ifdef __CYGWIN__
> >+ /*
> >+ * On cygwin, lstat("hello", &st) returns 0 when
> >+ * "hello.exe" exists, so test with open() again.
> >+ */
> >+ if (lstat(match, &st) && -1 != (fd = open(match,
> >O_RDONLY))) {
>
> This does not "test again" if lstat returns 0. If lstat returns 0
> (file stat info
> obtained) the open is not even called. Besides, cygwin lies not only about
> .exe but also about .lnk files.
>
> P.S. Somehow I have the feeling that even if it is a stupidity in cygwin
> they will not fix it (nor will they admit it is a bug).
They will not. Because it is not a bug. It seems to be (part of) workaround
to get programs written for unix work in windows.
One reason for such workaround I can think of is, that some programs try to
find themselves and since their argv[0] often does NOT contain the extension,
the stat has to succeed for them.
Using open here unfortunately won't work though, because:
- For stale links open will fail, but the lstat should succeed. This does
apply to cygwin, because cygwin emulates links.
- I'd expect open to actually succeed in this case, because there are
programs that don't only try to find themselves, but also open themselves,
because they bundle some data.
Another problem is, that the file might exist or might be cygwin artefact and
there does not seem to be an easy way to tell.
IMHO the described problem is harmless (you know the file does not exist, so
you should have no reason to add it and nothing happens if you don't) and
happens very rarely (adding binaries to version control is usually not a good
idea), so I suggest to let this be, as the workaround can easily cause other
problems.
--
Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
