On 2020-09-24 06:01, Michael McMahon via Cygwin wrote: > > > On 24/09/2020 12:26, Ken Brown wrote: >> On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote: >>> Hi, >>> >>> I searched for related issues but haven't found anything. >>> >>> I am having some trouble with Windows native Unix domain sockets >>> (a recent feature in Windows 10 and 2019 server) and Cygwin. >>> I think I possibly know the cause since I had to investigate a similar >>> looking issue on another platform built on Windows. >>> >>> The problem is that cygwin commands don't seem to recognise native Unix >>> domain sockets correctly. For example, the socket "foo.sock" should >>> have the same ownership and similar permissions to other files >>> in the example below: >>> >>> $ ls -lrt >>> total 2181303 >>> >>> -rw-r--r-- 1 mimcmah None 1259 Sep 23 10:22 test.c >>> -rwxr-xr-x 1 mimcmah None 3680 Sep 23 10:22 test.obj >>> -rwxr-xr-x 1 mimcmah None 121344 Sep 23 10:22 test.exe >>> -rw-r----- 1 Unknown+User Unknown+Group 0 Sep 23 10:23 foo.sock >>> -rw-r--r-- 1 mimcmah None 144356 Sep 23 10:27 check.ot >>> >>> A bigger problem is that foo.sock can't be deleted with the cygwin "rm" >>> command. >>> >>> $ rm -f foo.sock >>> rm: cannot remove 'foo.sock': Permission denied >>> >>> $ chmod 777 foo.sock >>> chmod: changing permissions of 'foo.sock': Permission denied >>> >>> $ cmd /c del foo.sock >>> >>> But, native Windows commands are okay, as the third example shows. >>> >>> I think the problem may relate to the way native Unix domain sockets are >>> implemented in Windows and the resulting special handling required. >>> They are implemented as NTFS reparse points and when opening them >>> with CreateFile, you need to specify the FILE_FLAG_OPEN_REPARSE_POINT >>> flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other >>> complications unfortunately, which I'd be happy to discuss further. >>> >>> But, to reproduce it, you can compile the attached code snippet >>> which creates foo.sock in the current directory. Obviously, this >>> only works on recent versions of Windows 10 and 2019 server. >> >> Cygwin doesn't currently support native Windows AF_UNIX sockets, as you've >> discovered. See >> >> >> https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$ >> >> for the current state of AF_UNIX sockets on Cygwin, including the possibility >> of using native Windows AF_UNIX sockets on systems that support them. >> >> If all you want is for Cygwin to recognize such sockets and allow you to >> apply >> rm, chmod, etc., I don't think it would be hard to add that capability. But >> I >> doubt if that's all you want. >> >> Further discussion of this will have to wait until Corinna is available. >> > > Thanks for the info. It's mainly about recognition of sockets for > regular commands. Since these objects can exist on Windows filesystems > now, potentially created by any kind of Windows application, > it would be great if Cygwin could handle them, irrespective of whether > the Cygwin development environment does. Though that sounds like a > good idea too.
See recent discussion: https://cygwin.com/pipermail/cygwin/2020-June/245077.html -- 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. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
