Mail Archives: cygwin/2019/09/23/19:47:48
On 2019-09-23 17:24, Jürgen Wagner wrote:
> On 24.09.2019 00:26, Andrey Repin wrote:
>> Greetings, Brian Inglis!
>>
>>> On 2019-09-23 09:02, Ken Brown wrote:
>>>> On 9/23/2019 10:42 AM, Mark Zhitomirski wrote:
>>>>> While trying different path names I've hit the following crash:
>>>>>
>>>>> $ ls \\\\\?\\DRIVE\\
>>>>> 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 -ld \\\\\?\\C:\\
>> drwxr-xr-x 1 anrdaemon None 0 сен 13 23:19 '\\?\C:\'
>>
>> WJFFM
>>
>>>> Thanks for the report. I can confirm the crash. I'll look into it.
>>> Although:
>>> $ ll $SYSTEMDRIVE\\
>>> lists normally, the owner and group is the current user, whereas the correct
>>> owners and groups are shown by:
>>> $ ll /proc/cygdrive/c/
>> That did not work for me, both show current user:group.
>> For reference,
>>
>> fstab:
>> none / cygdrive noacl,binary,nouser,posix=0 0 0
>>
>> $ mount
>> …
>> C: on /c type ntfs (binary,noacl,posix=0,noumount,auto)
>>
>>> and Cygwin really does not like the entries in:
>>> $ ll \\\\\?\\*\\
>>> use of any name instead of *, or none causes a crash:
>>> $ ll \\\\\?\\Boot\\
>>> $ ll \\\\\?\\
>> I wonder, what have you tried to reach here?
> 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.
UNC paths require Windows path \\?\UNC\share\dir\... or
shell \\\\\?\\UNC\\share\\...
> 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.
These Win 32 name space paths are equivalent to Windows NT name space paths
\\GLOBAL??\... created by driver symlinks between the name spaces.
For further info, have a look under /proc/sys/...!
> 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.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -