ls \\\\\?\\DRIVE\\ Aborted (core dumped)
Jürgen Wagner
juergen@wagner.is
Mon Sep 23 23:46:00 GMT 2019
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3469 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20190923/90a3c254/attachment.p7s>
More information about the Cygwin
mailing list