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
