X-Spam-Check-By: sourceware.org
Date: Fri, 3 Feb 2006 22:59:53 +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: <20060203215953.GI15572@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <020320061629 DOT 15609 DOT 43E384D300027AED00003CF922007610640A050E040D0C079D0A AT comcast DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <020320061629.15609.43E384D300027AED00003CF922007610640A050E040D0C079D0A@comcast.net>
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:29, Eric Blake wrote:
> > > 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.
> 
> I don't know - on Linux, you can have both TESTLINK and
> TESTLINK.exe in the same directory, whether or not either file
> is an actual file or a symlink.  There definitely needs to be a

The difference her is the special meaning of .exe under Windows.  If you
have an executable "foo" under Linux, it's called "foo".  Under Windows
it's called "foo.exe" and unfortunately there's still room left to
create an entirely unrelated file "foo".  But if both files have the
executable bit set, which one to execute if the user calls "foo"?
There's an unwanted ambiguity here.  Not that I want to push the problem
to coreutils, but I think in the long run, Cygwin should refuse to
create a file "foo" if "foo.exe" is present and vice versa.  The same
goes for "foo.lnk".  All three filenames, "foo", "foo.exe", "foo.lnk"
are in our virtual POSIX reality denoting one and the same file "foo",
just cluttered with Windows naming convention ambiguity.  What we want
from the POSIX perspective is ideally only one file "foo" per directory,
isn't it?

> foo, foo.exe  (both regular files)
> foo.lnk, foo.exe (symlink, regular file)
> foo, foo.exe.lnk (regular file, symlink)
> foo.lnk, foo.exe.lnk (both symlinks)

Therefore I can't agree to this list, though I understand what
you're up to.

> Meanwhile, are you asking for a cygwin-specific patch to ln that
> refuses to create a symlink foo{,.exe} if the current directory
> already contains the alternate symlink foo{.exe,}?  It might be
> better if this were folded into symlink(2), instead of burdening
> ln(1).

Ideally it should be in symlink, I agree.  But symlink doesn't care
right now and if it should care at one point, then only in the context
of an entirely tranparent .exe handling.  I don't ask for a patch to
coreutils, I just expressed my general dissatisfaction with the situation.

> >  I know that this should actually be
> > handled in Cygwin, and I have a patch in the backyard which adds
> > transparent .exe handling to Cygwin, but this is a big behavioral change
> > and we must proceed carefully with that.
> 
> Agreed, per my above conversation about transparent handling
> of the Windows .lnk suffix.  What does your patch actually try to
> do with .exe?

The idea is just simply to add automatic .exe handling to functions
which are not doing this so far, because it has been thought of as "too
dangerous".  I'm talking about open(2), link(2), rename(2), unlink(2),
basically.  You're right, symlink(2) would be another candidate which I
forgot so far (*making mental note*).  The result is in some way what I
outlined above.  Consider a link("foo", "bar") in a directory in which a
file bar.exe already exists.  Without transparent .exe handling, link
would create a hardlink called "bar".  With transparent .exe handling
the link function would encounter the existance of a file "bar.exe" and
refuse to create the symlink with EEXIST.


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/