Semantic difference with/without CYGWIN=winsymlinks:nativestrict

[Paul Townsend <aab@purdue.edu>]

Attempts to make symlinks are handled differently depending on (1) whether or not the target file pre-exists and (2) whether or not CYGWIN=winsymlinks:nativestrict is exported.  Actually,  'ln' seems to require the pre-existence as if it were a hard link attempt when CYGWIN is defined.  FWIW -  'ln' on Ubuntu 18.04 on WSL (Windows Subsystem for Linux) allows the target to be nonexistent.

The following is a very simplistic example:


 $ unset CYGWIN

 $ rm a b

 $ ln -s a b

 $ ls -l a b

 ls: cannot access 'a': No such file or directory
 lrwxrwxrwx 1 aab None 1 Sep  6 03:45 b -> a       <=<=< not a "real" Windows type symlink
 $ export CYGWIN=winsymlinks:nativestrict
 $ rm a b
 $ ln -s a b
 ln: failed to create symbolic link 'b': No such file or directory
 $ rm a b
 rm: cannot remove 'a': No such file or directory
 rm: cannot remove 'b': No such file or directory
 $ touch a
 $ ln -s a b
 $ ls -l a b
-rw-r--r-- 1 aab None 0 Sep  6 03:55 a
lrwxrwxrwx 1 aab None 1 Sep  6 03:55 b -> a
 $ rm a b

Found above when I downloaded the source for 'bash-4.4' and 'cygport'/'tar' attempted to make the symlink
    bash-4.4/ChangeLog -> [bash-4.4/]CWRU/changelog
which did not yet exist.  The error message is a bit confusing but it implies that the destination must pre-exist in order for the symlink to be made.  FWIW - With CYGWIN exported as shown above, 'ln' does create real symlinks as verfied by Windows 10 File Explorer.

--    Thanks



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple