From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.19+: symlink bug
Date: Fri, 03 Feb 2006 16:29:07 +0000
Message-Id: <020320061629.15609.43E384D300027AED00003CF922007610640A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> > 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
restriction that if TESTLINK exists as a real file, then you cannot
use cygwin to also create TESTLINK.lnk as a symlink (although
cygwin needs to be tolerant of the ability of Windows backdoor
creation of two files with the same transparent name).

My idea of sane behavior (although this is not the current
cygwin behavior, nor do I know if others will agree with my
idea) is as follows.  Cygwin should allow the following
combinations of Windows filenames to exist in a single
directory:

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)

In all four cases above, I would then expect lstat("foo") to
return information on the first, and lstat("foo.exe") to return
information on the second.  I would also expect 
symlink("bar", "foo.lnk") and creat("foo.lnk", 0777) to fail with
EINVAL or ENOENT (while not specified by SUSv3, this would
make it obvious that the filename to create contains invalid
characters by explicitly listing the .lnk suffix, similar to how
create("<") already returns ENOENT because Windows does
not like the filename).  Then lstat("foo.lnk") and
lstat("foo.exe.lnk") should also fail with ENOENT (since it
should never be possible to see the .lnk suffix of a
cygwin symlink).  Then on a managed mount, you could
make it possible to create files with a suffix of .lnk visible
via lstat() (something like foo.ln%6b for a regular file, or
foo.ln%6b.lnk for a symlink).

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).

>  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?  Is it like the above, where (except on managed
mounts, which encode to .ex%65 to keep the suffix visible to
lstat()) creat(2) refuses to create an .exe suffix, and lstat()
fails with ENOENT if passed an explicit .exe suffix?  It just might
work, but it will definitely need testing.  On the other hand,
this would make my earlier idea of permitting both foo and
foo.exe in the same directory impossible, except on managed
mounts, by making .exe an impossible suffix in non-managed
directories.

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