Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

["Matt D." <codespunk@gmail.com>]

I have a folder with a lot of native Windows symbolic links. I want to
copy this folder.

I cannot rsync or cp this folder due to Cygwin being unable to create
symbolic links without also wanting to verify the link target. This
can be demonstrated:

$ ln -s a b
ln: failed to create symbolic link 'b': No such file or directory

If I create a test directory folder_a/ and folder_b/. Inside I will
"touch a" and "ln -s a b".

I cannot rsync this folder:

$ rsync -a folder_a/ folder_b/
rsync: symlink "folder_a/b" -> "a" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1306) [sender=3.2.0dev]

Using "cp -a folder_a/* folder_b/" in this test case DOES work but
this is simply because files were returned in the correct order and
the link could be created.

This can be demonstrated where this works fine:

$ cp -a folder_a/a folder_a/b folder_b/

But this does not:

$ cp -a folder_a/b folder_a/b folder_b/
cp: cannot create symbolic link 'folder_b/b': No such file or directory
cp: warning: source file 'folder_a/b' specified more than once

The order in which files are returned while listing them in a
directory and necessitating their pre-existence while performing a
deep copy is impossible. It's also very normal for symbolic links to
exist which may or may not point to a valid target depending on the
observing path.

Windows does NOT require a link to be valid before creation. This can
be demonstrated with mklink:

C:\mklink b a
symbolic link created for b <<===>> a