And there is more fun:

$ ls -ldi D:/
1407374883553285 drwxr-xr-x 1 jw09030 Kein 0 Sep 16 09:02 D:/

$ ls -ldi \\\\\?\\a\\
1407374883553285 drwxr-xr-x 1 jw09030 Kein 0 Sep 16 09:03 '\\?\a\'

$ ls -ldi \\\\\?\\d\\
1407374883553285 drwxr-xr-x 1 jw09030 Kein 0 Sep 16 09:03 '\\?\d\'

$ ls -ldi \\\\\?\\d:\\
1407374883553285 drwxr-xr-x 1 jw09030 Kein 0 Sep 16 09:02 '\\?\d:\'

$ ls -ldi /cygdrive/d/.
1407374883553285 drwxrwx---+ 1 SYSTEM SYSTEM 0 Sep 16 09:02 /cygdrive/d/.

$ ls -ldi /cygdrive/d
1407374883553285 drwxrwx---+ 1 SYSTEM SYSTEM 0 Sep 16 09:02 /cygdrive/d

$ ls -ldi /d/.
1407374883553285 drwxrwx---+ 1 SYSTEM SYSTEM 0 Sep 16 09:02 /d/.

Notice how the \\? listing without the colon is one minute younger than 
the real directory... apart from the ownership changing. It's always the 
same inode, though.

$ ls -ldi \\\\\?\\d:\\
1407374883553285 drwxr-xr-x 1 jw09030 Kein 0 Sep 16 09:02 '\\?\d:\'

$ ls -ldi \\\\\?\\dd:\\
18014896789143535314 dr-xr-xr-x 1 jw09030 Kein 0 Sep 24 01:34 '\\?\dd:\'

$ ls -ldi \\\\\?\\ddd:\\
1407374883553285 drwxr-xr-x 1 jw09030 Kein 0 Sep 16 09:02 '\\?\ddd:\'

$ ls -ldi \\\\\?\\dddd:\\
assertion "p >= path" failed: file 
"/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", 
line 2916, function: int symlink_info::check(char*, const suffix_info*, 
fs_info&, path_conv_handle&)
Aborted (core dumped)

The inode number which is different from the actual inode number of D:/ 
is not present on drive C: or drive D:. At least, "find" did not turn up 
anything.

Cheers,
--j.

On 24.09.2019 01:24, Jürgen Wagner wrote:
> The whole interpretation of paths of this sort seems to be inconsistent.
>
> ls \\\\\?\\c:\\
> => lists C:/
>
> ls \\\\\?\\d:\\
> => lists D:/
>
> ls \\\\\?\\blah:\\
> assertion "p >= path" failed: file 
> "/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", 
> line 2916, function: int symlink_info::check(char*, const 
> suffix_info*, fs_info&, path_conv_handle&)
> Aborted (core dumped)
>
> ls \\\\\?\\c\\
> => lists C:/
>
> ls \\\\\?\\d\\
> => lists C:/ (in fact, it lists the contents of the top folder of the 
> drive your current working directory is located in)
>
> ls \\\\\?\\a\\
> => lists C:/ (in fact, there is no drive A: on my system)
>
> ls \\\\.\\d:\\
> ls: cannot access '\\.\d:\': Not a directory
> => The alternative notation with a "." does not seem to be understood. 
> It works in DOS shells.
>
> ls //\?/d:/
> ls: cannot access '//?/d:/': Not a directory
> => The replacement notation with forward slashes (which works with UNC 
> paths) does not seem to be honored here.
>
> It seems to me the device notation is not really implemented in 
> Cygwin, and if invalid device paths are used or strange, invalid 
> syntactic forms are used, this fails with a core dump.
>
> This is on CYGWIN_NT-10.0 saraswati 3.0.7(0.338/5/3) 2019-04-30 18:08 
> x86_64 Cygwin on a Dell 5470 with the latest Windows 10 version.
>
> Best regards,
> --Jürgen
>