From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id EAC793972039 for ; Thu, 24 Sep 2020 17:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EAC793972039 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id LUlpkINlVs3D6LUlqkrRgO; Thu, 24 Sep 2020 11:11:02 -0600 X-Authority-Analysis: v=2.4 cv=bZHV7MDB c=1 sm=1 tr=0 ts=5f6cd326 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=uherdBYGAAAA:8 a=w_pzkKWiAAAA:8 a=HJ7KC8MjIp7L4YDGm3IA:9 a=QEXdDO2ut3YA:10 a=xmOgoB5tJq8A:10 a=cVSPFhKjkqgA:10 a=Ef4yma5cpRUEJWN9UqBm:22 a=sRI3_1zDfAgwuvI8zelB:22 Reply-To: cygwin@cygwin.com Subject: Re: Problems with native Unix domain sockets on Win 10/2019 To: cygwin@cygwin.com References: <2b0aeab4-983d-e1d7-301f-edfeeb38cc85@oracle.com> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: <445fc4db-739c-7569-926b-739ebd1ffbf9@SystematicSw.ab.ca> Date: Thu, 24 Sep 2020 11:11:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfLs4l9jdtX8PKRr55SJD4VJVX9xKqTgenXUfbwD6IjiF2AkwEc2VvvYGpOfRyhmwXLNOxKbLm/I1m8usg1ySmIU81bg8EhWUSYq7DdvbncXNVgR+Fhrv lsAOqr3e/LOFPliOJeFNIppLlfDZgjPLBMvnXI3jIFkbsqDv27BS6ph71itLBBPUUJnEyunjJgxEB4Tg7iJkeKHKsFx8Tya56pE= X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 17:11:04 -0000 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.]