This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.19+: symlink bug


On Feb  3 22:59, Corinna Vinschen wrote:
> 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?
> [...]
> 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.

If you want to give it a try, I added the experimental "transparent_exe"
option to $CYGWIN.  The functions behaving differently are

- open("foo") opens "foo.exe" if it exists, but "foo" doesn't.
- rename("foo", "bar") will rename foo.exe to bar.exe.
- unlink("foo") will unlink foo.exe
- link, symlink will ... yes, right.
- pathconv("foo") will report on foo.exe.
- realpath will only append the .exe suffix if transparent_exe is not
  set.
- /proc/$PID/exe{name} will only keep the .exe suffix if transparent_exe
  is not set.

That's it so far.  Keep in mind that this is experimental and will
stay experimental for some time, so there's no good reason to rip the
extra CYGWIN functionality from coreutils right now ;-)

Bugs in the transparent_exe handling won't be a showstopper for a Cygwin
release, but I would appreciate some relaxed testing and bug reporting.

Don't use this option on production systems, though.


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]