git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Hudec <bulb@ucw.cz>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Liu Yubao <yubao.liu@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] remove unnecessary loop
Date: Tue, 8 May 2007 12:13:17 +0200	[thread overview]
Message-ID: <20070508101317.GC9007@efreet.light.src> (raw)
In-Reply-To: <81b0412b0705080208x3713cbc1y3c870383b586c877@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Tue, May 08, 2007 at 11:08:35 +0200, Alex Riesen wrote:
> On 5/8/07, Liu Yubao <yubao.liu@gmail.com> 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@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-05-08 10:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08  3:18 [PATCH] remove unnecessary loop Liu Yubao
2007-05-08  4:49 ` Liu Yubao
2007-05-08  5:05   ` Junio C Hamano
2007-05-08  9:08   ` Alex Riesen
2007-05-08 10:13     ` Jan Hudec [this message]
2007-05-08 12:38       ` Alex Riesen
2007-05-08 12:17     ` Eric Blake
2007-05-08  9:39   ` Jan Hudec
2007-05-09  1:03     ` Liu Yubao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070508101317.GC9007@efreet.light.src \
    --to=bulb@ucw.cz \
    --cc=git@vger.kernel.org \
    --cc=raa.lkml@gmail.com \
    --cc=yubao.liu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).