From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by sourceware.org (Postfix) with ESMTPS id 5EE6E385802A for ; Sun, 31 Jan 2021 23:30:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5EE6E385802A Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 10VNUuTv006004; Sun, 31 Jan 2021 23:30:56 GMT Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 36cxvqtysf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 31 Jan 2021 23:30:56 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 10VNUowE062502; Sun, 31 Jan 2021 23:30:55 GMT Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by aserp3020.oracle.com with ESMTP id 36dhbvx09f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 31 Jan 2021 23:30:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXOUOTbRJw1aWgp8QxBsYb9pSpLP7tcn8FOE/g1RsOx6YqiXi/XeaBrVj/X9yKK/5EK0tMXBlYDBAxJDKU2Ya/9wwD1d5VpMl2awwPIRYf7z9PtRahaGzpbD7IfDvMgae53BOlAyO2pB54JypE0vpsWB+bKzqcUI2ax66SZL2NIrkkA6N/AjEJ7rc1oyng0AV/B/wQ1CSvjW5E1SHaOZLFLTXT1lzL355SujaVqeSiEhN5s0acME0HPTZ4gxHdlGgfpESxJF54Bprz5phOpazukxADf+4AhuC4zG+J6VSfhx0VpEpymhu/kTyXl98DD4hJvGpyQSlZx8Vj5H3mNr4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M1O0ddsoRnEruGwtw3o+T3ou2pfjtGZhH/zWfmcDUIU=; b=DqrrhB6b7ZFyXpXeUZiz76ZOWdRoDwgNWYCfmIAg++UGaGouD8puW+ydXyKqI18ckL6TxbvR61qB+22PXKCPpKbm6RbBCkFbg0UA8+4cXrjaux/2trQsRwI5xo1ywVKquRpwGaO76UJSHmSORLlAcC0FtSu6C0cM4jbuSkVBpvBKaDaKEIUZ1Ys9++SFsmEwlXJxBGT/ukctqHGEbxp/C+n5ByYdMet6nChEKKNqe2nHUWOxb8FievByejY6T/Lc80uG4YPo5dN6exbKK9TTVvq+PymoQ9tNk3sWdI2+juwBqYswaR5eJhiO3HAdk9igq/PqXqgiatM0vzLqiu83+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from DM6PR10MB3929.namprd10.prod.outlook.com (2603:10b6:5:1fb::18) by DM6PR10MB3369.namprd10.prod.outlook.com (2603:10b6:5:1a7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.17; Sun, 31 Jan 2021 23:30:52 +0000 Received: from DM6PR10MB3929.namprd10.prod.outlook.com ([fe80::b830:40c:5bc6:af06]) by DM6PR10MB3929.namprd10.prod.outlook.com ([fe80::b830:40c:5bc6:af06%3]) with mapi id 15.20.3805.025; Sun, 31 Jan 2021 23:30:52 +0000 Subject: Re: Problems with native Unix domain sockets on Win 10/2019 To: Ken Brown , cygwin@cygwin.com References: <2b0aeab4-983d-e1d7-301f-edfeeb38cc85@oracle.com> <97d2b3af-224a-6873-fb4a-55a0ae9cd379@cornell.edu> <3e3cfe17-7fda-b063-4885-9114db9e748d@cornell.edu> <70b5577f-2cf1-0110-5d3b-cb2bd8ee6df2@cornell.edu> <69ad720c-8ea6-d3bb-b0a5-5556c4550091@oracle.com> <2d85550f-d753-4055-8b93-35e5287a9a93@oracle.com> From: Michael McMahon Message-ID: Date: Sun, 31 Jan 2021 23:30:46 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 In-Reply-To: Content-Language: en-US X-Originating-IP: [2001:bb6:319:458:e104:a0f2:a923:b19e] X-ClientProxiedBy: DB7PR02CA0036.eurprd02.prod.outlook.com (2603:10a6:10:52::49) To DM6PR10MB3929.namprd10.prod.outlook.com (2603:10b6:5:1fb::18) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from Michaels-MacBook-Pro.local (2001:bb6:319:458:e104:a0f2:a923:b19e) by DB7PR02CA0036.eurprd02.prod.outlook.com (2603:10a6:10:52::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.17 via Frontend Transport; Sun, 31 Jan 2021 23:30:51 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d2f156a7-236f-473b-a11e-08d8c6403fdf X-MS-TrafficTypeDiagnostic: DM6PR10MB3369: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tnUbBAKG0rXcwaPAiAV5RZ0XdX3Npml2j8wptJseCfsJmaGL2pXNTWCTpRjTEYCOwqkQfJns7tRafvSExi5A4fvRDjPvS54pH9acGpj6uzf5Udis0VCx3JSaVDUxZnGaDBbEKpUNMq0tY7X+vTavqEA5fIWA7xd2AOIPspKqQ3Q0LfJSiIHgXqTkfdFPVyGzh0yvHzTDi3looSrLBaD2TfTB3AC4nFEAGAUXZW8EFkb8ry6gORFg/vYljIfjjslaarByPmF7oPefkKNpBebdSLapTZ6A0AlCUgkpAJj1reRXL0QqXc6FVwH1Bqm7MNqicdwS2aXo9dlK97I0T2Tapc3fgDpl4fFHBo48tECm/DyWX91q2rKoCrdSkIQVLF5MchCDZufySOAguawIE3XhgAb+270zzqp+Wmdnr1j58FOGPNAVjwO4HqfKQ51+u+zQVP4ScBsri8fbrgtebzdBcEunBxgSBuWz90ODK0uAwX4znIyfVZAve7WTJSqN/lnStUAjmGpQ7ligrigncpr7ndWXzwfvnXNpKppchCR3Sp2k6LERy53ZSCezSMqqkqnWUJc5tbEb05EvWcZcKsa+L7kLiU6+UCwwiA1hkkAqHDrx51yGc3JdbGj8uISTfwecVK7S/0Qm86rIMGu87SpnMDT5NEgBZ4rwMC4Mj9uj75zx1PSFJ4MT5whlkTedgb/GXYL/773CZV7CB5eDMODdpuF1eD3wio4/6ReDszrYHN+qXbHpYChnJOqlpClKLEz6 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR10MB3929.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(366004)(376002)(396003)(39860400002)(316002)(6666004)(36756003)(8936002)(6486002)(66574015)(6512007)(83380400001)(31686004)(166002)(186003)(2906002)(53546011)(30864003)(478600001)(31696002)(966005)(86362001)(6506007)(8676002)(66476007)(66556008)(66946007)(5660300002)(16526019)(2616005)(43740500002)(45980500001)(460985005)(2480315003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?n70jIFYKPVUSKfIOi5DcbZxeWMe3PrVpdT6MMhK10KXke+q2MQ+CMSf+?= =?Windows-1252?Q?MwwM1p+j5YzqQL0Rl0TOB5IrxiRYW4ATFrUAwMtEw4274/CiQ7tzdVBO?= =?Windows-1252?Q?h8kX7bPUEr1p8NGws3fdun09dwhutrL++lnjJvFxSY+RyCvHHYS7q9jY?= =?Windows-1252?Q?F+vvxRS3XqGs+x+g5B++rOHWRwsGOY+02PW55bmKRHMD/S2xO4DDcdYM?= =?Windows-1252?Q?w7a09upt0Xd8GRUotmzshiGci0/d51iGLZJYcAiIPVEDf9NfTrF4HkVS?= =?Windows-1252?Q?pMYFRxzSVRZ0uO2MVP/zKTbGJoRagHzH3Vvb+RcNqHqZpKyDcSp2J6EM?= =?Windows-1252?Q?qBpelkEINKmmUFthwDvwRtoN1pTppkLEk/8t+H0PA116XK7d6YiiCmiw?= =?Windows-1252?Q?lv8EbHCxKnf3o8Si0sBhCRYgR0FiVf21gqr5eaotXKgHzITAnlKgKEXT?= =?Windows-1252?Q?Us8pPcBMyNZL4HH7unB9ht1mOjtiUcaePs9UyYRBCcjGzy/99/XAooOa?= =?Windows-1252?Q?MnVMKZ+r4+qXKv9pZhji7W0RQqXmfU6APdjnMHC2E6CeeFPxZe2Rzzh3?= =?Windows-1252?Q?16zZHjZk/lcQI9u2RYMlVgQiaVQRXSCQJxG3wfQX23P++upaGatds6fm?= =?Windows-1252?Q?egDkD4LuNEaC6AqQ5osKhfTYO8IKrQ78uu+eo3hPWZ6k/rpBgmzPfRnK?= =?Windows-1252?Q?eJzV8X9OoaFRIELVJ4qOTwPYzQGUtClUTGm+fR+JLAqzq9U+zH9vQh3P?= =?Windows-1252?Q?lP8rDnBRcNoi4TTPYMrt/fCXO+/1kRbH6kykLz1CikI4ANgUHgbIYz/e?= =?Windows-1252?Q?RoNVYIe/L6zK0whsn3OGK1IytvLpoKu9fGSbXwGcsNH/HGj7p8cJWtAA?= =?Windows-1252?Q?nrgSBmgtVzK6B4WA7w5U/vpDDKPOYKt2pTG4bJYyHbKxXlCK7rhvCEPJ?= =?Windows-1252?Q?GuZH4bF1R/rTpuoqGZDJJrsj3CDyEb/0FytWwV73vUT93sUn8PuaA1Fc?= =?Windows-1252?Q?FRRYsG9Gvmk7f419YjyovbcIJJvSrVcJ3BDT1Z9rlt5v/LDuIOx9A+om?= =?Windows-1252?Q?oJVrups8PJ6fGJ2xwLPrRh3ej/2DASAQTROngmvazx9LF8pT0DZ1te4M?= =?Windows-1252?Q?bDPaXmb68egY4K/ZegdLwp84/QooPN2SXSSKwOEc9ZxvgLrfysbCjMMK?= =?Windows-1252?Q?sZuAeO8L1R/02W3hRTpkhaBHGipkI04D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2f156a7-236f-473b-a11e-08d8c6403fdf X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB3929.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2021 23:30:52.6900 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: g3K9xjelcsqpOvgvXRReVoLst8nSR0rmGMzWMdPr3SYIM9Ec7wua2TNdcBuuZ7rGz81wDUBrJC/0z8i+tp+gyn64ijzGvPll8vE+Z2uuZbc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB3369 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9881 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101310137 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9881 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101310137 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 31 Jan 2021 23:31:02 -0000 On 30/01/2021 16:00, Ken Brown wrote: > On 9/28/2020 7:03 AM, Michael McMahon wrote: >> >> >> On 26/09/2020 08:30, Michael McMahon via Cygwin wrote: >>> >>> >>> On 25/09/2020 21:30, Ken Brown wrote: >>>> On 9/25/2020 2:50 PM, Ken Brown via Cygwin wrote: >>>>> On 9/25/2020 10:29 AM, Michael McMahon wrote: >>>>>> >>>>>> >>>>>> On 25/09/2020 14:19, Ken Brown wrote: >>>>>>> On 9/24/2020 8:01 AM, Michael McMahon 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. >>>>>>> >>>>>>> I think this has a simple fix (attached), but I can't easily test >>>>>>> it because your test program doesn't compile for me. First, I got >>>>>>> >>>>>>> $ gcc -o native_unix_socket native_unix_socket.c >>>>>>> native_unix_socket.c:5:10: fatal error: WS2tcpip.h: No such file or >>>>>>> directory 5 | #include | ^~~~~~~~~~~~ compilation >>>>>>> terminated. >>>>>>> >>>>>>> I fixed this by making the include file name lower case.  (My >>>>>>> system is case sensitive, so it matters.) >>>>>>> >>>>>>> Next: >>>>>>> >>>>>>> $ gcc -o native_unix_socket native_unix_socket.c >>>>>>> native_unix_socket.c:8:10: fatal error: afunix.h: No such file or >>>>>>> directory 8 | #include | ^~~~~~~~~~ compilation >>>>>>> terminated. >>>>>>> >>>>>>> There's no file afunix.h in the Cygwin distribution, but I located >>>>>>> it online and pasted in the contents.  The program now compiles but >>>>>>> fails to link: >>>>>>> >>>>>>> $ gcc -o native_unix_socket native_unix_socket.c >>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: >>>>>>> >>>>>>>  /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): undefined >>>>>>> reference to `__imp_WSAStartup' >>>>>>> /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): relocation >>>>>>> truncated to fit: R_X86_64_PC32 against undefined symbol >>>>>>> `__imp_WSAStartup' >>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: >>>>>>> >>>>>>>  /tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): undefined >>>>>>> reference to `__imp_WSAGetLastError' >>>>>>> /tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): relocation >>>>>>> truncated to fit: R_X86_64_PC32 against undefined symbol >>>>>>> `__imp_WSAGetLastError' >>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: >>>>>>> >>>>>>>  /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): undefined >>>>>>> reference to `__imp_WSAGetLastError' >>>>>>> /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): relocation >>>>>>> truncated to fit: R_X86_64_PC32 against undefined symbol >>>>>>> `__imp_WSAGetLastError' collect2: error: ld returned 1 exit status >>>>>>> >>>>>>> This is probably easy to fix too, but I don't feel like tracking it >>>>>>> down. Please send compilation instructions (that use Cygwin >>>>>>> tools). >>>>>>> >>>>>>> Ken >>>>>> >>>>>> Hi >>>>>> >>>>>> Sorry, I had compiled it in a native Visual C environment. >>>>>> >>>>>> Assuming you have afunix.h in the current directory. >>>>>> >>>>>> gcc -o native_unix_socket -I. native_unix_socket.c -lws2_32 >>>>>> >>>>>> should do it. >>>>> >>>>> Thanks, that works.  But now I can't reproduce your problem.  Here's >>>>> what I see, using Cygwin 3.1.7 without applying my patch: >>>>> >>>>> $ ./native_unix_socket.exe getsockname works fam = 1, len = 11 >>>>> offsetof >>>>> clen = 9 strlen = 8 name = foo.sock >>>>> >>>>> $ ls -l foo.sock -rwxr-xr-x 1 kbrown None 0 2020-09-25 14:39 >>>>> foo.sock* >>>>> >>>>> $ chmod 644 foo.sock >>>>> >>>>> $ ls -l foo.sock -rw-r--r-- 1 kbrown None 0 2020-09-25 14:39 foo.sock >>>>> >>>>> $ rm foo.sock >>>>> >>>>> $ ls -l foo.sock ls: cannot access 'foo.sock': No such file or >>>>> directory >>>>> >>>>> I'm running 64-bit Cygwin on Windows 10 1909. >>>> >>>> I just ran the 'rm' command under gdb to see what's going on, and it >>>> seems that foo.sock is not being recognized as a reparse point.  So >>>> maybe >>>> your test program, when compiled and run under Cygwin, doesn't >>>> actually >>>> produce a native Windows AF_UNIX socket.  And when I try to run it >>>> in a >>>> Windows Command Prompt, I get >>>> >>>> bind failed 10050 getsockname failed 10022 >>>> >>>> Can you make your version of the test executable available for me >>>> to try? >>>> Or tell me some other way to create a native Windows AF_UNIX socket? >>>> >>>> Ken >>> >>> That is all very strange. I have checked both the gcc compiled and >>> MS compiled executables on my system (2019 server) and they are both >>> definitely producing native AF_UNIX sockets. >>> >>> I can email you the two exe files. They are both quite small. But, >>> first I >>> want to check the patch status of my test system. >>> >> >> So, it turns out that this issue only happens on some of our test >> systems. It >> does not happen on a personal copy of Windows 10 on my laptop either. >> >> I also noticed that some native Windows commands don't work properly >> on any >> affected system (eg 'attrib' or 'fsutil'). Though 'fsutil' can be >> used to >> verify that the reparse point is created correctly. >> >> Possibly, this was a Windows bug that has been fixed. It never made >> sense >> that you had to open socket files using the >> FILE_FLAG_OPEN_REPARSE_POINT flag, because you would have to know in >> advance that the file is a socket to >> be able to do this (or else be prepared to have to open the file >> twice). But, >> I don't fully understand yet, why some systems are affected and >> others not. All seem to be patched up to date. >> >> In any case, I think it's clear this isn't a Cygwin issue. > > It turns out that this is a Cygwin issue after all.  In a private message > Michael has said: > >> From what I can see, the only versions that are *not* affected by the >> problem >> are 1903 and 1909 (which you tested with).  Versions I have tested >> with since >> then (2004, and 20H2) all show the problem. > > I can't immediately test it myself because I'm still on 1909.  But > I'll send a patch to cygwin-patches that I think should fix it, along > with Michael's test program. > > Ken Thanks for taking this up again. While I had thought it was a Windows bug, and it is arguable, but at least there is a reasonable workaround for it. I'd be happy to test an update you have for it. Michael.