Catastrophic Cygwin find . -ls, grep performance on samba share compared to WSL&Linux

[Dan Shelton <dan.f.shelton@gmail.com>]

Hello!
I am unhappy to report a severe performance issue with find -ls, ls -R
and grep -r, with Cygwin 3.4.9 and Cygwin 3.5.0 when samba shares are
involved.

Imagine a directory with 256 subdirs, and each has 256 files per
subdir, all on a samba share, samba server is on Linux with tmpfs.

mkdir dir1
for ((i=0;i<256;i++)) ; do
    mkdir "dir1/subdir$i"
    for ((j=0; j < 256;j++));do
        echo  "j=$j" >"dir1/subdir$i/j$j.txt"
    done
done

Time comparisations then show a dramatic difference, Debian Linux
accessing the samba share, WSL accessing the samba share, and Cygwin
accessing the samba share:
1. time find . >/dev/null
Cygwin 86 seconds
WSL 23 seconds
Debian 19 seconds

2. time find . -ls >/dev/null
Cygwin 129 seconds
WSL 38 seconds
Debian 32 seconds

3. time grep -r -E NOMATCH 2>/dev/null
Cygwin 390 seconds
WSL 144 seconds
Debian 141 seconds

So where does the bad Cygwin performance come from? Virus checker,
memory compression and other Windows services known to interfere with
benchmarking are OFF.

But the network trace shows a dramatic difference: While Debian and
WSL open files only once, the Cygwin run spends lots of network
traffic checking whether the txt files are txt.lnk, txt,bat.lnk and so
on, all non existent files.

Why does that happen?
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd