X-Spam-Check-By: sourceware.org
Date: Fri, 3 Feb 2006 17:00:21 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.19+: symlink bug
Message-ID: <20060203160021.GG15572@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <020320061506 DOT 16175 DOT 43E371890007264300003F2F22073007930A050E040D0C079D0A AT comcast DOT net> <20060203154711 DOT GF15572 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060203154711.GF15572@calimero.vinschen.de>
User-Agent: Mutt/1.4.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Feb  3 16:47, Corinna Vinschen wrote:
> On Feb  3 15:06, Eric Blake wrote:
> > > > Creating links with the same name, but with and without a .exe extension
> > > > succeeds, but the one with no extension is later ignored.  Here's a
> > > > minimal example:
> > > > 
> > > Did you try this with the latest coreutils 5.93-3?
> > 
> > I just reproduced with stock cygwin 1.5.19 and coreutils 5.93-3.  The
> > behavior is the same, and it is cygwin doing it.  It appears that when
> > both TESTLINK.lnk and TESTLINK.exe.lnk exist, lstat("TESTLINK")
> > is picking up the contents of TESTLINK.exe.lnk rather than the
> > contents of TESTLINK.lnk.
> 
> I have prepared a patch which eliminates this problem, and I'll apply it
> soon, but nevertheless, I'm not exaclty happy with coreutils symlink
> handling.  If a TESTLINK exist, it shouldn't allow to create a
> TESTLINK.exe symlink, really.  [...]

...and vice versa.

Another problem is that the stat scanning order is (now)

  TESTLINK
  TESTLINK.exe
  TESTLINK.lnk
  TESTLINK.exe.lnk

while, when calling one of the exec(2) functions, the scanning order is
turned around:

  TESTLINK.exe
  TESTLINK
  TESTLINK.exe.lnk
  TESTLINK.lnk

since the idea is that it's more likely that the executable file has a
.exe suffix than not.  This results in the above case in the unfortunate
situation, that ./TESTLINK calls echo, not ls.

I don't know if it's a good idea to change the scanning order in case of
exec(2).  It's certainly a change in behaviour which could result in yet
another set of weird problems which we hadn't before.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/