Re: ln -s exe magic (coreutils 6.7-2)

[Eric Blake-1 <ebb9 at byu dot net>]

> Brian Dessent wrote:
> > Eric Blake wrote:
> 
> > when creating symlinks, I plan to still auto-append the .exe to the link
> > target if necessary (otherwise, exec*() succeeds but open() fails when
> > dereferencing the symlink), but not to the link name.
> 
> That sounds correct.  If open() fails on a link target that's missing an
> .exe, then it should not be able to create such a symlink with ln.  Or
> perhaps, it is possible, but doing so requires special effort, e.g. "ln
> -s foo bar."

It should always be possible to create dangling symlinks, and
then make them non-dangling later.  The way I see it:

~ if invoking ln, require the source to exist (but possibly
with implicit .exe), and make the target end in .exe if the
source did (including via implicit .exe)
~ if invoking ln --disable-exe-magic, require the source
to exist, but no longer use implicit .exe to find it, and
allow the creation of a suffixless target even when source
had .exe
~ if invoking ln -s, search for the source (finding relative
source in relation to dirname(target), not pwd), possibly
with implicit .exe; then
  - in 6.7 and source was found - make the target and the
target's contents end in .exe if the source did likewise (including
via implicit .exe)
  - in 6.9 and source was found - only make the target end in
.exe if explicitly asked, but make the target's contents end in
.exe if the source did likewise (including via implicit .exe)
  - either version, if the source is not found - create dangling
symlink, with the target's contents ending in .exe only if
explicit
~ if invoking ln -s --disable-exe magic, skip the search
for the source, and flat out create the symlink, even if it is
danling, with the target having an explicit .exe if requested
~ in all cases, if -f is also present for ln, make sure only
one of foo.lnk and foo.exe.lnk exists after the command
~ perhaps also make cp -f and mv -f smart enough
to make sure only one of foo.lnk and foo.exe.lnk exist,
but here I'm not so sure

In other words, the default behavior of 6.9 should never create
foo.exe.lnk unless you type the .exe, but the --disable-exe-magic
will let you do anything no matter how insane it is.

And with dangling symlinks, it is up to you to use .exe
correctly, or suffer the odd open() behavior because
you created the dangling symlink with contents that lacked
the necessary .exe.

In the case when both source and source.exe exist on a
non-managed mount, source. forces cygwin to consider
the non-.exe version.  Likewise, if target.exe exists, it
is still possible to use target. to force creation of target
rather than interfering with target.exe.

> > Therefore, in the original case, the first ln -s generates
> > sendmail->/usr/bin/exim, then the second ln -s overwrites it with
> > sendmail->/usr/sbin/ssmtp.exe rather than adding a new file.
> 
> Don't you mean the first ln -s generates "sendmail -> /usr/bin/exim.exe"
> and the second overwrites it with "sendmail -> /usr/bin/ssmtp.exe"?

No, because /usr/bin/exim is itself a symlink (correctly named without
suffix, in spite of coreutils 6.7's deficiency).

> > The other thing I am thinking about is making the coreutils postinstall
> > script go through /usr/bin and finding all instances of *.exe.lnk, and
> > rewriting those symlinks to be just *.lnk, taking care of Corinna's list
> > of symlinks with .exe in their name.  This won't catch everything, but
> it
> > will be a good chunk of the current issues, while transitioning towards
> > the point of preferring only *.lnk rather than *.exe.lnk for a symlink
> > name.  I wonder, though, if this will trip up cygcheck at all.
> 
> That sounds good at first, but whatever package created those symlinks
> will just recreate them again when reinstalled/updated, so I think the
> better plan would be to identify whatever is doing it and work with
> maintainers of those packages to update them.

I think I will go ahead with the postinstall script, along with a
message to cygwin-apps about all the packages that need to
be regenerated with coreutils 6.9 so that they no longer
embed an old-style foo.exe.lnk in their tarball.

-- 
Eric Blake

-- 
View this message in context: http://www.nabble.com/ln--s-exe-magic-%28coreutils-6.7-2%29-tf3078000.html#a9909394
Sent from the Cygwin Users mailing list archive at Nabble.com.


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