#926 ln -s directory does not work

MSYS
closed
MSYS (75)
invalid
Behaves_as_Documented
2013-01-18
2006-04-05
Rolf Ebert
No

NTFS file system on Windows XP.

$ uname -a
MINGW32_NT-5.1 PD69 1.0.10(0.46/3/2) 2004-03-15 07:17
i686 unknown

$ touch file
$ mkdir dir
$ ln -s file dir
ln: `dir': cannot overwrite directory
$ cp file dir

This should probably be fixed in the MSYS
implementation of ln.

Discussion

  • Keith Marshall

    Keith Marshall - 2007-09-18

    Logged In: YES
    user_id=823908
    Originator: NO

    Cesar,

    Reassigning to you for info only. It seems to be fixed in the latest coreutils build, so I've marked it as closed.

     
  • Keith Marshall

    Keith Marshall - 2007-09-18
    • milestone: --> 507559
    • assigned_to: earnie --> cstrauss
    • status: open --> closed-fixed
     
  • Cesar Strauss

    Cesar Strauss - 2010-02-19

    This is "broken" again on MSYS 1.0.13:

    $ uname -a
    MINGW32_NT-5.1 NOT2005 1.0.13(0.47/3/2) 2010-01-14 21:58 i686 Msys

    $ touch file
    $ mkdir dir
    $ ln -s file dir
    ln: creating symbolic link `dir/file' to `file': No such file or directory

    However, I don't think this test is reasonable.

    On a system with true symlinks (e.g. Cygwin), I end up with a recursive symlink:

    cygwin$ ls -l dir
    lrwxrwxrwx 1 cstrauss Nenhum 4 2010-02-19 10:24 file -> file
    cygwin$ cat dir/file
    cat: dir/file: Too many levels of symbolic links

    I can't expect MSYS ln -s to support this.

    If you want to test the ability to create a symlink in a directory, perhaps a more reasonable test would be:

    $ touch file
    $ mkdir dir
    $ ln -s ../file dir

    which fails on 1.0.11, but succeeds on 1.0.13.

    I see the former (IMHO unreasonable) test is included in modern autoconf (which is how I came across to this issue). I plan to raise the issue on their mailing list.

    Regards,
    Cesar

     
  • Cesar Strauss

    Cesar Strauss - 2010-02-19
    • milestone: 507559 --> Behaves_as_Documented
    • status: closed-fixed --> closed-invalid
     
  • Rolf Ebert

    Rolf Ebert - 2010-02-21

    I think the original test case is reasonable as it is typical unix behaviour. I did not make it up. The Makefile in gcc/ada creates a subdirektory rts/ and tries to create sympolic links in it to the run time source files which are in the current directory.

    As long as this use case of 'ln -s' does not work the gcc Ada compiler cannot be built in a MSYS environment without patching the Makefile.

    Rolf

     
  • Cesar Strauss

    Cesar Strauss - 2010-02-21

    It does work as you intend, as long as the source is an absolute pathname:

    $ touch /tmp/file
    $ mkdir dir
    $ ln -s /tmp/file dir
    $ ls dir
    file

    Since the Ada Makefile does uses absolute source pathnames, it's should work OK.

    On the other hand, the Ada Makefile uses the LN_S variable set by configure. Since configure detects that MSYS doesn't support dangling or recursive symlinks, it sets LN_S = "cp -p" as a fallback.

    So, Ada Makefiles won't be using ln -s on MSYS anyway.

    As for relative source pathnames, the behaviour was adjusted according to the bug report #1798825: ln -s does not work with relative target path

    https://sourceforge.net/tracker/index.php?func=detail&aid=1798825&group_id=2435&atid=102435

    Regards,
    Cesar

     
  • Earnie Boyd

    Earnie Boyd - 2013-01-18
    • status: closed-invalid --> closed
    • resolution: --> invalid
    • category: --> Behaves_as_Documented
    • milestone: Behaves_as_Documented --> MSYS
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks