On Mon, Jul 03, 2017 at 03:31:22PM +0200, Corinna Vinschen wrote:
> I uploaded a new Cygwin release 2.8.1-1

This has introduced a regression that I'm seeing when running `ls` on
some network shares.  I can reproduce the behaviour with an install of
only the base Cygwin packages, and the behaviour disappears if I
downgrade back to v2.8.0-1.

(Apologies for the obfuscation in the below report; I'm not clear on
what I'm authorised to disclose about my work network, and so erring
on the side of caution.)

Specifically, if I run `ls -l` or `ls --color=always` over certain
directories on one of my company's Windows network shares, I sometimes
see errors stating:

    ls: cannot access '//path/to/file/in/listed/share': Bad address

The file that is listed in the error message appears as below in the
`ls -l` output:

    -?????????? ? ?                  ?                    ?
?  <filename>

When this happens, the file is also coloured by `ls` as if it were not
executable; with v2.8.0-1 the file is correctly marked as executable.

Alternatively, in some circumstances when `ls`ing that directory, I
see no output whatsoever.  This seems to happen in particular when
accessing the directory via a two-hop symlink, i.e. something created
like this:

    $ ln -s //path/to/share symlink1

    $ ln -s symlink1 symlink2

    $ ls -l symlink1/
    <list of files>

    $ ls -l symlink2/

    $

The behaviour doesn't seem to be entirely consistent, and I haven't
been able to characterise when this behaviour occurs and when it
doesn't, even on the same directory.

Given the behaviour seems to reliably not occur when running a bare
`ls`, I'm guessing the problem is relating to how Cygwin is parsing
the file permissions.

I've attached redacted `cygcheck -srv` output.

Cheers,

Adam