Re: [Mingw-users] MSYS ln -s to directory

[Ralf W. <Ral...@gm...>]

[ This is http://thread.gmane.org/gmane.comp.gnu.mingw.user/19363
  aka http://sourceforge.net/mailarchive/message.php?msg_id=15310041
  and for replies, please note that mingw-users posters need
  subscription; quoting generously for the Autoconf crowd. ]

* Keith MARSHALL wrote on Wed, Apr 05, 2006 at 12:08:48PM CEST:
> Rolf Ebert wrote:
> > $ mkdir dir
> > $ ln -s Makefile dir
> > ln: `dir': cannot overwrite directory
> > $ cp Makefile dir

> > I wonder how a clean solution should look like.  Shouldn't gcc's
> > configure script detect that ln -s does *not* work correctly and
> > substitute it by cp? Is it just my msys installation where ln -s
> > does not work correctly with directories?
> 
> Nope.  It's a bug in the MSYS implementation of `ln'.

> MSYS doesn't support symbolic links, at all, but it does support
> *hard* links for *files*, (but *not* directories), on NTFS *only*,
> (i.e. not on FAT*).  The `ln' command will create such hard links,
> where supported; in all other cases it is *supposed* to behave as
> if `cp' were invoked instead, and indeed, this works as advertised:

> So, it's fine for `ln -s file1 file2'.  However, extending this
> example, it fails when the final argument to `ln -s' is a named
> directory:
> 
>   $ mkdir bar
>   $ ln -s hello hello.sh bar
>   ln: `bar': cannot overwrite directory
>   ln: `bar': cannot overwrite directory
> 
> But, this special case *does* work:
> 
>   $ cd bar
>   $ ln -s ../hello .
>   $ ls
>   hello
>   $ ./hello
>   Hello, World!
> 
> Do note that, in all cases, the links are created as simple file
> copies, rather than as symbolic links in the *nix sense:

OK to apply this to detect this in Autoconf?
Could somebody test that this detects the MSYS behavior, please?

The `rm -f conf$$.dir' at the beginning (rather than a rmdir or rm -rf)
is on purpose: if someone has such a leftover file, I'd like to know
(plus I'm real nervous about any occurrences of `rm -rf').

Thanks,
Ralf

	* lib/m4sugar/m4sh.m4 (_AS_LN_S_PREPARE): MSYS `ln -s' fails 
        with a target directory; it's internally implemented as `cp' 
        anyway, but since Autoconf advertises the possibility to use
        a target directory when LN_S is `ln -s', we need to find out.
	Reported by Rolf Ebert <rol...@gm...> against MSYS,
        analyzed by Keith Marshall <kei...@to...>.

Index: lib/m4sugar/m4sh.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v
retrieving revision 1.175
diff -u -r1.175 m4sh.m4
--- lib/m4sugar/m4sh.m4	5 Apr 2006 08:01:05 -0000	1.175
+++ lib/m4sugar/m4sh.m4	6 Apr 2006 16:53:02 -0000
@@ -854,11 +856,13 @@
 # Don't use conftest.sym to avoid file name issues on DJGPP, where this
 # would yield conftest.sym.exe for DJGPP < 2.04.  And don't use `conftest'
 # as base name to avoid prohibiting concurrency (e.g., concurrent
-# config.statuses).
+# config.statuses).  MSYS `ln -s' fails with a target directory.
 m4_defun([_AS_LN_S_PREPARE],
-[rm -f conf$$ conf$$.exe conf$$.file
+[rm -f conf$$ conf$$.exe conf$$.file conf$$.dir
+test -d conf$$.dir || mkdir conf$$.dir
 echo >conf$$.file
-if ln -s conf$$.file conf$$ 2>/dev/null; then
+if ln -s conf$$.file conf$$ 2>/dev/null &&
+   ln -s conf$$.file conf$$.dir 2>/dev/null; then
   # We could just check for DJGPP; but this test a) works b) is more generic
   # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04).
   if test -f conf$$.exe; then
@@ -872,7 +876,8 @@
 else
   as_ln_s='cp -p'
 fi
-rm -f conf$$ conf$$.exe conf$$.file
+rm -f conf$$ conf$$.exe conf$$.file conf$$.dir/conf$$.file
+rmdir conf$$.dir
 ])# _AS_LN_S_PREPARE