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