Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address failed: annas1stee...@aol.com: SMTP error from remote server for TEXT command, host: mx-aol.mail.gm0.yahoodns.net (67.195.204.80) reason: 554 30 Sorry, your message to annas1stee...@aol.com cannot be delivered. T his mailbox is disabled (554.30). --- The header of the original message is following. --- Received: from winhex19beeu8.wineu.mail ([10.72.140.144]) by mri.eue.server.lan (mrieue103 [10.74.38.52]) with ESMTPS (Nemesis) id 1McJUA-1t9WGd3z6y-00kEJt for ; Wed, 05 Feb 2025 06:07:15 +0100 Received: from [50.114.115.99] (10.72.140.251) by winhex19beeu8.wineu.mail (10.72.140.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.13; Wed, 5 Feb 2025 06:07:14 +0100 Content-Type: multipart/mixed; boundary="===2672155318372224407==" MIME-Version: 1.0 From: =?UTF-8?Q?Job Alerts Wioa?= To: Subject: =?UTF-8?Q?Wioa Job Opportunities for You?= Date: Wed, 5 Feb 2025 05:07:13 + Message-ID: <173873203391.11080.3898966286140147...@cygwin.com> X-Accept-Language: en-us, en Return-Path: cygwin@cygwin.com X-ClientProxiedBy: winhex19beeu26.wineu.mail (10.72.140.154) To winhex19beeu8.wineu.mail (10.72.140.144) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:qLjYv3jsVcY=;Y8SK/bJmzGKT+Y8lTHKMnKzsq4u DkdBnDe0X9o/b3gPnswb3CFhJMy6FTSEC5t40JQrUHG7YbYzASvCbxsb6CW2Ch/ebHfMrzqH0 //EOdjjpYQBK+YMDxi7gBuYy6P2bzmXZyvBX4Zf9lq+7XSYSpnS1dY6+YVwKf7WkF6x8QMMkQ ZLlUC19i0qcc4KsBZLUKcT62fToHVP+aHV23tCqC/Fm4vI0Oz2VCqfOKhyfUpff9hmDMQuV1o ydDAyeP76pN0zFxk0Wu5jqDjTRgcNp+I85VC1a/l/sgGBl7MbmbpPOse8w4x3LYxza+Qn0Cca pU3GhdtCplGrIeufU9tWGl5P8/1r8StCjBhU/qLgwjuzozdUS69kpemDBZkdet7iQu0g/L9fj 7rxmiyNLxi6pwUf8h98qB2QEexSb1TRzz9URkSvqX7dT7TqTLUAfYiqCyBPxMZaEp/0U/xiCv +bHWyANjJm7v5xLG4G/3alI4Mrp2slVqC+1agmUcdEIt5JWfY+E70oR8YSvgO/E9LGKL5Ni4u 3cjiiJdYBNUsWqmGpiwQeRdb9uMag984JOIYdAUZmHCqnx2S36SURGNjoMTurP4HvnjEcHev6 bPirrgW5+6Z9yu+76qecBLHu9tEZ0itG+LwLt2dGS5JH5rlZegaQVqx5H428/D82wNhT+4Af0 IjE+sIDWeKdDlzj1zS5NHhijf5C9EeNW7utw2B1BWrpNa60SocnZlrdbhibqaBOejw80xYKo0 X8AdOm7EvDLaj/6uBnlV9Fj4Qna68b/Q9Wum9ZCl9dpbalcTlbFhILjFB4nXkRtEGcv1fcMQV ear9wwheRVFvfj/dv5X/64zV6WdI/Yyinqlrg1J06aN0ah3hkyMxsHLZ3sBLvKwndmKMn9EbQ oOVSW+h5zmDHj6nP6dTXnpmMhDQKamA+UaE28fEXYc7N08w4O7tZcW+FB Reporting-MTA: dns;kundenserver.de Arrival-Date: Wed, 05 Feb 2025 06:07:15 +0100 Final-Recipient: rfc822;annas1steeden@aol.com Action: failed Status: 5.0.0 Final-Log-ID: 1McJUA-1t9WGd3z6y-00kEJt Received: from winhex19beeu8.wineu.mail ([10.72.140.144]) by mri.eue.server.lan (mrieue103 [10.74.38.52]) with ESMTPS (Nemesis) id 1McJUA-1t9WGd3z6y-00kEJt for ; Wed, 05 Feb 2025 06:07:15 +0100 Received: from [50.114.115.99] (10.72.140.251) by winhex19beeu8.wineu.mail (10.72.140.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.13; Wed, 5 Feb 2025 06:07:14 +0100 Content-Type: multipart/mixed; boundary="===2672155318372224407==" MIME-Version: 1.0 From: =?UTF-8?Q?Job Alerts Wioa?= To: Subject: =?UTF-8?Q?Wioa Job Opportunities for You?= Date: Wed, 5 Feb 2025 05:07:13 + Message-ID: <173873203391.11080.3898966286140147...@cygwin.com> X-Accept-Language: en-us, en Return-Path: cygwin@cygwin.com X-ClientProxiedBy: winhex19beeu26.wineu.mail (10.72.140.154) To winhex19beeu8.wineu.mail (10.72.140.144) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:qLjYv3jsVcY=;Y8SK/bJmzGKT+Y8lTHKMnKzsq4u DkdBnDe0X9o/b3gPnswb3CFhJMy6FTSEC5t40JQrUHG7YbYzASvCbxsb6CW2Ch/ebHfMrzqH0 //EOdjjpYQBK+YMDxi7gBuYy6P2bzmXZyvBX4Zf9lq+7XSYSpnS1dY6+YVwKf7WkF6x8QMMkQ ZLlUC19i0qcc4KsBZLUKcT62fToHVP+aHV23tCqC/Fm4vI0Oz2VCqfOKhyfUpff9hmDMQuV1o ydDAyeP76pN0zFxk0Wu5jqDjTRgcNp+I85VC1a/l/sgGBl7MbmbpPOse8w4x3LYxza+Qn0Cca pU3GhdtCplGrIeufU9tWGl5P8/1r8StCjBhU/qLgwjuzozdUS69kpemDBZkdet7iQu0g/L9fj 7rxmiyNLxi6pwUf8h98qB2QEexSb1TRzz9URkSvqX7dT7TqTLUAfYiqCyBPxMZaEp/0U/xiCv +bHWyANjJm7v5xLG4G/3alI4Mrp2slVqC+1agmUcdEIt5JWfY+E70oR8YSvgO/E9LGKL5Ni4u 3cjiiJdYBNUsWqmGpiwQeRdb9uMag984JOIYdAUZmHCqnx2S36SURGNjoMTurP4HvnjEcHev6 bPirrgW5+6Z9yu+76qecBLHu9tEZ0itG+LwLt2dGS5JH5rlZegaQVqx5H428/D82wNhT+4Af0 IjE+sIDWeKdDlzj1zS5NHhijf5C9EeNW7utw2B1BWrpNa60SocnZlrdbhibqaBOejw80xYKo0 X8AdOm7EvDLaj/6uBnlV9Fj4Qna68b/Q9Wum9ZCl9dpbalcTlbFhILjFB4nXkRtEGcv1fcMQV ear9wwheRVFvfj/dv5X/64zV6WdI/Yyinqlrg1J06aN0ah3hkyMxsHLZ3sBLvKwndmKMn9EbQ oOVSW+h5zmDHj6nP6dTXnpmMhDQKamA+UaE28fEXYc7N08w4O7tZcW+FB -- 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
Re: Potential Argument Injection Issue in Cygwin's Command Line Handling
On Wed, Feb 05, 2025 at 11:45:10AM +0800, Splitline Ng via Cygwin wrote:
> Hi Marco,
>
> > $ python3.12
> > Python 3.12.8 (main, Jan 31 2025, 21:29:51) [GCC 12.4.0] on cygwin
> > Type "help", "copyright", "credits" or "license" for more information.
> > import subprocess
> > subprocess.run(['./test.exe', '"', " a b c"])
> > argv[0] = ./test
> > argv[1] = "
> > argv[2] = a b c
> > CompletedProcess(args=['./test.exe', '"', ' a b c'], returncode=0)
> >
> > it seems correct to me for a Cygwin Python
>
> This behavior appears correct for Cygwin Python because it assumes it
> is running on a POSIX system. As a result, it uses Cygwin's simulated
> `execve` system call rather than Windows' command-line parsing
> mechanism and the parsing mechanism within Cygwin itself is consistent
> so everything goes fine here.
> To be more specific, the issue happens when a program thinks it is
> still on Windows, so it uses Microsoft C startup convention to escape
> and pass command line string and spawn that executable with
> CreateProcess API. But it turns out Cygwin C startup function doesn't
> fully follow that convention.
>
> > PS: Windows is not very consistent on quoting behaviour, e.g.
> > https://github.com/Azure/azure-cli/blob/dev/doc/quoting-issues-with-powershell.md
>
> I think we should distinguish between shell parsing and command-line
> parsing -- command-line parsing is all done by the executable itself
> instead of the shell (powershell, cmd, bash etc.)
> On Windows, arguments are parsed by the executable itself rather than
> the shell. This means the shell does not pass an argv[] array directly
> to the executable but instead sends the full command line string. Here
> is a good article about this
> https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN
>
> Regards,
> splitline
>
> On Tue, Feb 4, 2025 at 2:15 PM Splitline Huang wrote:
> >
> > Hello Cygwin team,
> >
> > I am splitline from DEVCORE research team. I recently have observed an
> > inconsistency
> > in how Cygwin handles command-line parsing compared to Microsoft’s
> > implementation.
> >
> >
> > According to Microsoft’s documentation [1], the \" sequence should always be
> > interpreted as a literal double quote ("):
> > > A double quote mark preceded by a backslash (\") is interpreted as a
> > > literal
> > > double quote mark (").
> >
> > However, in Cygwin, the same sequence treats the backslash as a literal
> > character
> > and starts quote mode instead.
> >
> > [1]
> > https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments
> >
> > This inconsistency can cause unexpected behavior when passing executable
> > arguments
> > via the command line (as opposed to Cygwin’s `execve` method), potentially
> > leading
> > to argument injection vulnerabilities.
> >
> >
> > Below is my testing process using the Python from Python.org (not the
> > Cygwin version):
> >
> >
> > splitline@SPLITLINE0D06 ~
> >
> > $ which gcc
> >
> > /usr/bin/gcc
> >
> > splitline@SPLITLINE0D06 ~
> >
> > $ cat test.c
> >
> > #include
> >
> >
> > int main(int argc, char* argv[], char* envp[]) {
> >
> > for (int i = 0; i < argc; ++i)
> >
> > printf("argv[%d] = %s\n", i, argv[i]);
> >
> > }
> >
> > splitline@SPLITLINE0D06 ~
> >
> > $ gcc test.c -o test.exe
> >
> > splitline@SPLITLINE0D06 ~
> >
> > $ which python
> >
> > /cygdrive/c/Python313/python
> >
> > splitline@SPLITLINE0D06 ~
> >
> > $ python
> >
> > Python 3.13.1 (tags/v3.13.1:0671451, Dec 3 2024, 19:06:28) [MSC v.1942
> >
> > 64 bit (AMD64)] on win32
> >
> > Type "help", "copyright", "credits" or "license" for more information.
> >
> > >>> import subprocess
> >
> > >>> subprocess.run(['./test.exe', '"', " a b c"]) # should be only 2 args
> >
> > argv[0] = ./test
> >
> > argv[1] = \
> >
> > argv[2] = a
> >
> > argv[3] = b
> >
> > argv[4] = c
> >
> > CompletedProcess(args=['./test.exe', '"', ' a b c'], returncode=0)
> >
> > >>>
> >
> >
> >
> > As we can see, it should originally be only 2 arguments: ["] and [ a b c].
> > However,
> > the command line is parsed into 4 different arguments.
> >
> > Note: With that Python code, the spawned command line is: ./test.exe \" " a
> > b c"
> >
> > Please let me know if you have any questions, thanks!
> >
> > Best regards,
> > splitline
> > DEVCORE
Windows is security deficient in this area, not Cygwin.
I'll quote myself to share my opinion:
https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/fdevent_win32.c#L543
* The Microsoft CreateProcess() interface is criminally broken.
* Forcing argument strings to be concatenated into a single string
* only to be re-parsed by Windows can lead to security issues.
*
* Above comment from 2021 was true then as now in 2025
*
https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/
Cheers, Glenn
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.c
Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address failed: anncliffo...@aol.com: SMTP error from remote server for TEXT command, host: mx-aol.mail.gm0.yahoodns.net (67.195.204.75) reason: 554 30 Sorry, your message to anncliffo...@aol.com cannot be delivered. Th is mailbox is disabled (554.30). --- The header of the original message is following. --- Received: from winhex19beeu22.wineu.mail ([10.72.140.152]) by mri.eue.server.lan (mrieue103 [10.74.38.52]) with ESMTPS (Nemesis) id 1N782c-1tN6pv1WQu-00xVNY for ; Wed, 05 Feb 2025 08:43:59 +0100 Received: from [50.114.115.99] (10.72.140.251) by winhex19beeu22.wineu.mail (10.72.140.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.13; Wed, 5 Feb 2025 08:43:58 +0100 Content-Type: multipart/mixed; boundary="===2325211465953490286==" MIME-Version: 1.0 From: =?UTF-8?Q?Job Alerts Wioa?= To: Subject: =?UTF-8?Q?Wioa Job Opportunities for You?= Date: Wed, 5 Feb 2025 07:43:57 + Message-ID: <173874143742.11080.3211763780944049...@cygwin.com> X-Accept-Language: en-us, en Return-Path: cygwin@cygwin.com X-ClientProxiedBy: winhex19beeu10.wineu.mail (10.72.140.145) To winhex19beeu22.wineu.mail (10.72.140.152) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Sn7jvWF+EQs=;OQhUq7EOq1ZeSJlVg7qXLGrTtrr wpobmVSqJSSUTjevVV7eI7wXoIhP602WmIRNy3NmWWpPYEwYC3IPeYF+b9qlW/cvhz6jycH+3 kB574s5UbPSbK4PPQxDR9VSTecpv3PR4EbcuoprDJrtN1vbJGNM9CTWq1CBovXuL6OjRUHF1S Crj+rrFvOl20Lhpk+G93c4wjBmWicZjjcKeYeDjfEMNPNLcxLi7KVtJf6Oy4yzBX7oFYtYYC0 wUNEPm5zmNh7FyicFZEADTWrTXbb1HLeDzlQ5PjyBfy8CVIlQOuQjEt2g+ok4RlcyipUmOkEW m2KFZxSnMUDmRh5ao80EapD3X0WLBYU1E5Qv/vD6ypP1tin7MeUMx9ByjdlHULaiJEdZdl1rp l8SCY2klexz8xMceMg6nQRTuLCpvn8PgzpUWlx9SqjH6xGEk3wtSQkBwGzcC//umCO906BbPk ElSGRf4hOrtwRqIkyX+jWAAK2bB+Ut3e9fNzS3rpjGVSTSAyylVYk07m37P1Ab0ja89XYMy/m TNhB545IfzaLr/oxfIyZWrndp7O3gpMp6Qg/6ETWIy0FcdPKg8NCc7n/k3gd7AnPMpWrfEQGH lYFvOSRaJPcz8U1YqrXzti3ErO9oXlAegjS1N9f9FWt74ZLfLSABFxW9peNqnzFm3TdD8B8yj MtIZrnWznxgoSZ4ndhSnUfJ9vtl+NUudly2/kuws2TVU9MVIYOAPq1Lfv88bTWOPYKqYCxfV2 g2Ohe/biaNwA7GiYye9d2w1tdii6EOYlTxA7brQ+KCBOs+3HGrzP/oNoHA3ybGjyfRwSzlHAT 9IbI0eDCRB0sHHFnRYbhCNcDNxFjMyb62hIGrd4Kf+3LBaobPwKZsFeaCxlRXym+XfQ5STtQl 9o4wKC9BqX5NTC7u8uLNNmUJnr/oUscNfRioVNYe2XVSEuA4nANeeS6Fl Reporting-MTA: dns;kundenserver.de Arrival-Date: Wed, 05 Feb 2025 08:43:59 +0100 Final-Recipient: rfc822;annclifford1@aol.com Action: failed Status: 5.0.0 Final-Log-ID: 1N782c-1tN6pv1WQu-00xVNY Received: from winhex19beeu22.wineu.mail ([10.72.140.152]) by mri.eue.server.lan (mrieue103 [10.74.38.52]) with ESMTPS (Nemesis) id 1N782c-1tN6pv1WQu-00xVNY for ; Wed, 05 Feb 2025 08:43:59 +0100 Received: from [50.114.115.99] (10.72.140.251) by winhex19beeu22.wineu.mail (10.72.140.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.13; Wed, 5 Feb 2025 08:43:58 +0100 Content-Type: multipart/mixed; boundary="===2325211465953490286==" MIME-Version: 1.0 From: =?UTF-8?Q?Job Alerts Wioa?= To: Subject: =?UTF-8?Q?Wioa Job Opportunities for You?= Date: Wed, 5 Feb 2025 07:43:57 + Message-ID: <173874143742.11080.3211763780944049...@cygwin.com> X-Accept-Language: en-us, en Return-Path: cygwin@cygwin.com X-ClientProxiedBy: winhex19beeu10.wineu.mail (10.72.140.145) To winhex19beeu22.wineu.mail (10.72.140.152) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Sn7jvWF+EQs=;OQhUq7EOq1ZeSJlVg7qXLGrTtrr wpobmVSqJSSUTjevVV7eI7wXoIhP602WmIRNy3NmWWpPYEwYC3IPeYF+b9qlW/cvhz6jycH+3 kB574s5UbPSbK4PPQxDR9VSTecpv3PR4EbcuoprDJrtN1vbJGNM9CTWq1CBovXuL6OjRUHF1S Crj+rrFvOl20Lhpk+G93c4wjBmWicZjjcKeYeDjfEMNPNLcxLi7KVtJf6Oy4yzBX7oFYtYYC0 wUNEPm5zmNh7FyicFZEADTWrTXbb1HLeDzlQ5PjyBfy8CVIlQOuQjEt2g+ok4RlcyipUmOkEW m2KFZxSnMUDmRh5ao80EapD3X0WLBYU1E5Qv/vD6ypP1tin7MeUMx9ByjdlHULaiJEdZdl1rp l8SCY2klexz8xMceMg6nQRTuLCpvn8PgzpUWlx9SqjH6xGEk3wtSQkBwGzcC//umCO906BbPk ElSGRf4hOrtwRqIkyX+jWAAK2bB+Ut3e9fNzS3rpjGVSTSAyylVYk07m37P1Ab0ja89XYMy/m TNhB545IfzaLr/oxfIyZWrndp7O3gpMp6Qg/6ETWIy0FcdPKg8NCc7n/k3gd7AnPMpWrfEQGH lYFvOSRaJPcz8U1YqrXzti3ErO9oXlAegjS1N9f9FWt74ZLfLSABFxW9peNqnzFm3TdD8B8yj MtIZrnWznxgoSZ4ndhSnUfJ9vtl+NUudly2/kuws2TVU9MVIYOAPq1Lfv88bTWOPYKqYCxfV2 g2Ohe/biaNwA7GiYye9d2w1tdii6EOYlTxA7brQ+KCBOs+3HGrzP/oNoHA3ybGjyfRwSzlHAT 9IbI0eDCRB0sHHFnRYbhCNcDNxFjMyb62hIGrd4Kf+3LBaobPwKZsFeaCxlRXym+XfQ5STtQl 9o4wKC9BqX5NTC7u8uLNNmUJnr/oUscNfRioVNYe2XVSEuA4nANeeS6Fl -- 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
Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ?
On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote: > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for > "remote" filesystems: > snip > 2582/* Don't handle junctions on remote filesystems as > symlinks. This type > 2583 of reparse point is handled transparently by the OS so that > the > 2584 target of the junction is the remote directory it is > supposed to > 2585 point to. If we handle it as symlink, it will be mistreated > as > 2586 pointing to a dir on the local system. */ > > The matching code in our filesystems seems to work in PowerShell and > cmd.exe - so what context am I missing ? The comment seemed to explain it pretty well. Junctions are always absolute. If it is absolute to a local path, that path is local to the server, not the client. If Cygwin treated it as a symlink, it would see the target as /cygdrive/c/whatever and would try to follow that to the client-local directory. By *not* treating those as symlinks, it will instead treat them as ordinary directories to be traversed, which will allow the OS to handle them as normal. Perhaps it could be relaxed to allow remote junctions to be treated as symlinks if their targets are UNC rather than local? Is that the case your filesystems are exposing? -- 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
|IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ?
Hi!
I am tinkering with Win32 reparse point (Junction) support and tried
to implement |IO_REPARSE_TAG_MOUNTPOINT| (and other reparse tags) in
our filesystems (mostly for automounter+NFSv4.1 referral support), but
it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
"remote" filesystems:
snip
2576if ((rp->SymbolicLinkReparseBuffer.Flags &
SYMLINK_FLAG_RELATIVE) ||
2577check_reparse_point_string (psymbuf))
2578 return PATH_SYMLINK | PATH_REP;
2579 }
2580else if (!remote && rp->ReparseTag == IO_REPARSE_TAG_MOUNT_POINT)
2581 {
2582/* Don't handle junctions on remote filesystems as
symlinks. This type
2583 of reparse point is handled transparently by the OS so that the
2584 target of the junction is the remote directory it is
supposed to
2585 point to. If we handle it as symlink, it will be mistreated as
2586 pointing to a dir on the local system. */
2587RtlInitCountedUnicodeString (psymbuf,
snip
The matching code in our filesystems seems to work in PowerShell and
cmd.exe - so what context am I missing ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
--
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
Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address failed: annamce...@aol.com: SMTP error from remote server for TEXT command, host: mx-aol.mail.gm0.yahoodns.net (98.136.96.93) reason: 554 30 Sorry, your message to annamce...@aol.com cannot be delivered. This mailbox is disabled (554.30). --- The header of the original message is following. --- Received: from winhex19beeu8.wineu.mail ([10.72.140.144]) by mri.eue.server.lan (mrieue002 [10.74.32.56]) with ESMTPS (Nemesis) id 1MeEA3-1t6zr037Ml-00qSCM for ; Wed, 05 Feb 2025 04:09:33 +0100 Received: from [50.114.115.99] (10.72.140.251) by winhex19beeu8.wineu.mail (10.72.140.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.13; Wed, 5 Feb 2025 04:09:32 +0100 Content-Type: multipart/mixed; boundary="===7864255997305007386==" MIME-Version: 1.0 From: =?UTF-8?Q?Job Alerts Wioa?= To: Subject: =?UTF-8?Q?Wioa Job Opportunities for You?= Date: Wed, 5 Feb 2025 03:09:31 + Message-ID: <173872497183.11080.8345263168293424...@cygwin.com> X-Accept-Language: en-us, en Return-Path: cygwin@cygwin.com X-ClientProxiedBy: winhex19beeu4.wineu.mail (10.72.140.142) To winhex19beeu8.wineu.mail (10.72.140.144) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:aXqxf6aGU7w=;5m6F7iz29NsdSVe5MATub65/HEZ cia492XjlPSzPPog8pERCZboc+mUgYk38AOdrZfl/2ao/Sqwbnwq6KIRt1ndlDdgiw1cB4uKR 0rdGid4XzmQeLKPCtR7hKfLrCFOfPjor/hIFOY27SVH2+fFc0cZ/zr9ByJ7u8RQxyS6bZekiv 0qXHXYVTHt8J1SnhRdmQb+UCVD7FP+L7vLb8avALN1x5Ntl+a/Vq8gXbYz5Hq4y/QV+qVLOA0 Aa4eP2dtd1RLhh/JwAk+HyoES6no0h2E2t0G3sKIyA5s9hjWgnerTQyzbRZmUYmmJbUP4HBQn qj2+l2rnGEgZJztYHrkGgpCGbzeDnhVBepEJRQcpggrsG1tq82WqLr/YbJW8giaXvW78EQ/S7 CFXpejQb+ZwfVOyhI4xf/Z6wjewib0TsvgPQSWx5y0f7xur7rmrqgIbqIh6Bw4O5QxXf88KpK F6SSqcG7/Yqwn7M8B8n0R3HltedSABiTn1pKexF1cKKBYN3aW0F8kHwgqLdk10S8hbjPruzp4 2Vd4rGwi3u7vpmYCjB2TkdifQbAR1vzNnwrAqLl/4sGhOs8yETb4+gq3mpWERT9Jo2CiAe3V2 QFU1BWntKdMkgRQvzHxpGfz6imjU44UAbd8tE/RVdC/aJDba7xUYGshcct4l+QaUNa6zukzRl KjH9mCjZ6/2uxR7LYx+86IOuCgGpkeXp1UJctmp2IDF5Rpgx8q6WOywNHxDkw8/jFXLWJaSv6 FlPUVsQRhgFBCCDf88jgkTSpHpGQNshWVyceuoF0RJuIfjjIyvSZQl7VXCcTsyl3ouy6V8kly gYOT3inJBmqC4vMfIB6RnwK4A4Lqva0xqBK4ol12OZQ1k3BWQM/JYf/SOEYpfT7xNLFH1AndM JEzqnmoWdp4UrMAj9US8znoGfLZ0lwFD64U/UZWnmW3VJqqjZOQKbY0P8 Reporting-MTA: dns;kundenserver.de Arrival-Date: Wed, 05 Feb 2025 04:09:33 +0100 Final-Recipient: rfc822;annamcevoy@aol.com Action: failed Status: 5.0.0 Final-Log-ID: 1MeEA3-1t6zr037Ml-00qSCM Received: from winhex19beeu8.wineu.mail ([10.72.140.144]) by mri.eue.server.lan (mrieue002 [10.74.32.56]) with ESMTPS (Nemesis) id 1MeEA3-1t6zr037Ml-00qSCM for ; Wed, 05 Feb 2025 04:09:33 +0100 Received: from [50.114.115.99] (10.72.140.251) by winhex19beeu8.wineu.mail (10.72.140.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1544.13; Wed, 5 Feb 2025 04:09:32 +0100 Content-Type: multipart/mixed; boundary="===7864255997305007386==" MIME-Version: 1.0 From: =?UTF-8?Q?Job Alerts Wioa?= To: Subject: =?UTF-8?Q?Wioa Job Opportunities for You?= Date: Wed, 5 Feb 2025 03:09:31 + Message-ID: <173872497183.11080.8345263168293424...@cygwin.com> X-Accept-Language: en-us, en Return-Path: cygwin@cygwin.com X-ClientProxiedBy: winhex19beeu4.wineu.mail (10.72.140.142) To winhex19beeu8.wineu.mail (10.72.140.144) X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:aXqxf6aGU7w=;5m6F7iz29NsdSVe5MATub65/HEZ cia492XjlPSzPPog8pERCZboc+mUgYk38AOdrZfl/2ao/Sqwbnwq6KIRt1ndlDdgiw1cB4uKR 0rdGid4XzmQeLKPCtR7hKfLrCFOfPjor/hIFOY27SVH2+fFc0cZ/zr9ByJ7u8RQxyS6bZekiv 0qXHXYVTHt8J1SnhRdmQb+UCVD7FP+L7vLb8avALN1x5Ntl+a/Vq8gXbYz5Hq4y/QV+qVLOA0 Aa4eP2dtd1RLhh/JwAk+HyoES6no0h2E2t0G3sKIyA5s9hjWgnerTQyzbRZmUYmmJbUP4HBQn qj2+l2rnGEgZJztYHrkGgpCGbzeDnhVBepEJRQcpggrsG1tq82WqLr/YbJW8giaXvW78EQ/S7 CFXpejQb+ZwfVOyhI4xf/Z6wjewib0TsvgPQSWx5y0f7xur7rmrqgIbqIh6Bw4O5QxXf88KpK F6SSqcG7/Yqwn7M8B8n0R3HltedSABiTn1pKexF1cKKBYN3aW0F8kHwgqLdk10S8hbjPruzp4 2Vd4rGwi3u7vpmYCjB2TkdifQbAR1vzNnwrAqLl/4sGhOs8yETb4+gq3mpWERT9Jo2CiAe3V2 QFU1BWntKdMkgRQvzHxpGfz6imjU44UAbd8tE/RVdC/aJDba7xUYGshcct4l+QaUNa6zukzRl KjH9mCjZ6/2uxR7LYx+86IOuCgGpkeXp1UJctmp2IDF5Rpgx8q6WOywNHxDkw8/jFXLWJaSv6 FlPUVsQRhgFBCCDf88jgkTSpHpGQNshWVyceuoF0RJuIfjjIyvSZQl7VXCcTsyl3ouy6V8kly gYOT3inJBmqC4vMfIB6RnwK4A4Lqva0xqBK4ol12OZQ1k3BWQM/JYf/SOEYpfT7xNLFH1AndM JEzqnmoWdp4UrMAj9US8znoGfLZ0lwFD64U/UZWnmW3VJqqjZOQKbY0P8 -- 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
Re: Potential Argument Injection Issue in Cygwin's Command Line Handling
Hi Marco,
> $ python3.12
> Python 3.12.8 (main, Jan 31 2025, 21:29:51) [GCC 12.4.0] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
> import subprocess
> subprocess.run(['./test.exe', '"', " a b c"])
> argv[0] = ./test
> argv[1] = "
> argv[2] = a b c
> CompletedProcess(args=['./test.exe', '"', ' a b c'], returncode=0)
>
> it seems correct to me for a Cygwin Python
This behavior appears correct for Cygwin Python because it assumes it
is running on a POSIX system. As a result, it uses Cygwin's simulated
`execve` system call rather than Windows' command-line parsing
mechanism and the parsing mechanism within Cygwin itself is consistent
so everything goes fine here.
To be more specific, the issue happens when a program thinks it is
still on Windows, so it uses Microsoft C startup convention to escape
and pass command line string and spawn that executable with
CreateProcess API. But it turns out Cygwin C startup function doesn't
fully follow that convention.
> PS: Windows is not very consistent on quoting behaviour, e.g.
> https://github.com/Azure/azure-cli/blob/dev/doc/quoting-issues-with-powershell.md
I think we should distinguish between shell parsing and command-line
parsing -- command-line parsing is all done by the executable itself
instead of the shell (powershell, cmd, bash etc.)
On Windows, arguments are parsed by the executable itself rather than
the shell. This means the shell does not pass an argv[] array directly
to the executable but instead sends the full command line string. Here
is a good article about this
https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN
Regards,
splitline
On Tue, Feb 4, 2025 at 2:15 PM Splitline Huang wrote:
>
> Hello Cygwin team,
>
> I am splitline from DEVCORE research team. I recently have observed an
> inconsistency
> in how Cygwin handles command-line parsing compared to Microsoft’s
> implementation.
>
>
> According to Microsoft’s documentation [1], the \" sequence should always be
> interpreted as a literal double quote ("):
> > A double quote mark preceded by a backslash (\") is interpreted as a literal
> > double quote mark (").
>
> However, in Cygwin, the same sequence treats the backslash as a literal
> character
> and starts quote mode instead.
>
> [1]
> https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments
>
> This inconsistency can cause unexpected behavior when passing executable
> arguments
> via the command line (as opposed to Cygwin’s `execve` method), potentially
> leading
> to argument injection vulnerabilities.
>
>
> Below is my testing process using the Python from Python.org (not the Cygwin
> version):
>
>
> splitline@SPLITLINE0D06 ~
>
> $ which gcc
>
> /usr/bin/gcc
>
> splitline@SPLITLINE0D06 ~
>
> $ cat test.c
>
> #include
>
>
> int main(int argc, char* argv[], char* envp[]) {
>
> for (int i = 0; i < argc; ++i)
>
> printf("argv[%d] = %s\n", i, argv[i]);
>
> }
>
> splitline@SPLITLINE0D06 ~
>
> $ gcc test.c -o test.exe
>
> splitline@SPLITLINE0D06 ~
>
> $ which python
>
> /cygdrive/c/Python313/python
>
> splitline@SPLITLINE0D06 ~
>
> $ python
>
> Python 3.13.1 (tags/v3.13.1:0671451, Dec 3 2024, 19:06:28) [MSC v.1942
>
> 64 bit (AMD64)] on win32
>
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> import subprocess
>
> >>> subprocess.run(['./test.exe', '"', " a b c"]) # should be only 2 args
>
> argv[0] = ./test
>
> argv[1] = \
>
> argv[2] = a
>
> argv[3] = b
>
> argv[4] = c
>
> CompletedProcess(args=['./test.exe', '"', ' a b c'], returncode=0)
>
> >>>
>
>
>
> As we can see, it should originally be only 2 arguments: ["] and [ a b c].
> However,
> the command line is parsed into 4 different arguments.
>
> Note: With that Python code, the spawned command line is: ./test.exe \" " a b
> c"
>
> Please let me know if you have any questions, thanks!
>
> Best regards,
> splitline
> DEVCORE
>
--
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
Request to package perl module installer, App::cpanminus
ASSI, what about adding to the long list of packages you maintain another one, App::cpanminus, providing the commandline tool, 'cpanm', a popular alternative to the venerable CPAN, and the installer of choice of perl app developers? https://metacpan.org/pod/App::cpanminus https://github.com/miyagawa/cpanminus I am motivated to ask this by the efforts of the developer of App::perlbrew, a/the perl environment manager to extend support for cygwin, https://metacpan.org/pod/App::perlbrew https://github.com/gugod/App-perlbrew/pull/838#issuecomment-2631585142 which would be helped if there were a cpanm package. -- Greg "Dr Bean" Matheson Talk the talk. http://drbean.sdf.org Walk the walk. drb...@freeshell.org -- 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
Re: [Ms-nfs41-client-devel] Fwd: Implementing mkfifo, mknod support with NFS_SPECFILE_FIFO and NFS_SPECFILE_SOCK?
On Jan 31 14:23, Roland Mainz via Cygwin wrote:
> On Thu, Jan 30, 2025 at 2:34 PM Cedric Blancher
> wrote:
> [snip]
> > Does the ms-nfs41-client support NFS_SPECFILE_FIFO and NFS_SPECFILE_SOCK?
>
> No, but if Cygwin implements this for the Microsoft NFSv3 client then
> I'll add support for ms-nfs41-client and ms-nfs42-client ASAP.
>
> But I really would prefer if Cygwin would NOT use |NFS_SPECFILE_LNK|
> (all other |NFS_SPECFILE_*| would be OK), because it seems to be
> limited to |2050| bytes, while ms-nfs41-client/ms-nfs42-client doesn't
> have such a limit (currently supported are 4096 byte long paths, which
> sites like CERN&&Pasteur really use (measured by the bug reports about
> "... paths with 3280 bytes etc don't work...") ...).
>
> Question for Corinna:
> Why did Cygwin never use
> |NFS_SPECFILE_FIFO|/|NFS_SPECFILE_SOCK|/|NFS_SPECFILE_CHR| from
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/ff4df658-7f27-476a-8025-4074c0121eec
> ?
Because I didn't know about it until I read your mail.
The NFS code in Cygwin is basically from 2008. Back in those days, I
learned how to access NFS using EAs from a nice developer at Microsoft,
who worked on SFU at the time. There was never any communication about
an additional reparse point type, and I'm pretty sure it wasn't officially
documented at the time either.
However, testing is better than talking, so I quickly hacked up an STC:
$ cat > mk-dev-nfs.c <
#include
#include
typedef struct {
DWORD ReparseTag;
WORD ReparseDataLength;
WORD Reserved;
struct {
BYTE DataBuffer[1];
} GenericReparseBuffer;
struct {
ULONGLONG Type;
union {
struct {
ULONG Major;
ULONG Minor;
} Device;
WCHAR LnkBuffer[1];
};
} NfsReparseBuffer;
} MY_REPARSE_DATA_BUFFER, *MY_PREPARSE_DATA_BUFFER;
#define NFS_SPECFILE_LNK0x014B4E4CL
#define NFS_SPECFILE_CHR0x00524843L
#define NFS_SPECFILE_BLK0x004B4C42L
#define NFS_SPECFILE_FIFO 0x4F464946L
#define NFS_SPECFILE_SOCK 0x4B434F53L
int
main (int argc, char **argv)
{
HANDLE fh;
char buf[65536];
DWORD size_ret;
MY_PREPARSE_DATA_BUFFER rp;
if (argc < 3)
{
fprintf (stderr, "usage: %s b|c|f|s [major] [minor]\n", argv[0]);
return 1;
}
fh = CreateFile (argv[1],
GENERIC_WRITE,
0,
NULL,
CREATE_ALWAYS,
FILE_FLAG_BACKUP_SEMANTICS
| FILE_FLAG_OPEN_REPARSE_POINT,
NULL);
if (fh == INVALID_HANDLE_VALUE)
{
fprintf (stderr, "CreateFile: %d\n", GetLastError ());
return 1;
}
rp = (MY_PREPARSE_DATA_BUFFER) buf;
rp->ReparseTag = IO_REPARSE_TAG_NFS;
rp->ReparseDataLength = sizeof (ULONGLONG);
switch (argv[2][0])
{
case 'b':
case 'c':
if (argc != 5)
{
fprintf (stderr, "usage: %s b|c|f|s [major] [minor]\n",
argv[0]);
return 1;
}
rp->ReparseDataLength += 2 * sizeof (ULONG);
rp->NfsReparseBuffer.Type = argv[2][0] == 'b' ?
NFS_SPECFILE_BLK
: NFS_SPECFILE_CHR;
rp->NfsReparseBuffer.Device.Major = strtoul (argv[3], NULL, 0);
rp->NfsReparseBuffer.Device.Minor = strtoul (argv[4], NULL, 0);
break;
case 'f':
rp->NfsReparseBuffer.Type = NFS_SPECFILE_FIFO;
break;
case 's':
rp->NfsReparseBuffer.Type = NFS_SPECFILE_SOCK;
break;
}
rp->ReparseDataLength = sizeof (ULONGLONG) + 2 * sizeof (ULONG);
rp->NfsReparseBuffer.Type = NFS_SPECFILE_BLK;
if (! DeviceIoControl (fh, FSCTL_SET_REPARSE_POINT,
(LPVOID) buf,
REPARSE_GUID_DATA_BUFFER_HEADER_SIZE
+ rp->ReparseDataLength,
NULL, 0, &size_ret, NULL))
{
fprintf (stderr, "DeviceIoControl: %d\n", GetLastError ());
CloseHandle (fh);
DeleteFile (argv[1]);
return 1;
}
CloseHandle (fh);
return 0;
}
EOF
$ gcc -g ../src/mk-dev-nfs.c -o mk-dev-nfs
$ pwd
/home/corinna/tests/x86_64
$ mount | grep tests
//calimero.vinschen.de/cygwin/tests on /home/corinna/tests type nfs
(binary,user,bind)
So we're in an NFS-mounted directory, let's try to create a FIFO:
$ ./mk-dev-nfs
usage: ./mk-dev-nfs b|c|f|s [major] [minor]
$ ./mk-dev-nfs fifo f
DeviceIoControl: 50
$ ll fifo
ls: cannot access 'fifo': No such file or directory
$ ./mk-dev-nfs sock s
DeviceIoControl: 50
$ ./mk-dev-nfs blk b 0 0
DeviceIoControl: 50
$ ./mk-dev-nfs chr c 0 0
DeviceIoControl: 50
So... if you tell me what I'm doing wrong, I'm all ears.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/do
Re: [mintty] Problem of the control key on focus change
Hi Thomas, On Jan 30 21:59, Thomas Wolff via Cygwin wrote: > > Am 28.01.2025 um 09:56 schrieb Corinna Vinschen via Cygwin: > > On Jan 28 00:50, Thomas Wolff via Cygwin wrote: > > > Am 27.01.2025 um 12:17 schrieb Takashi Yano via Cygwin: > > > > Hi Thomas, > > > > > > > > A few days ago, Corinna asked me to check a problem of TTY. > > > > The problem is as follows. > > > > > > > > Reproduce steps: > > > > (1) Open mintty. > > > > (2) Open another mintty. > > > > (3) Place the second mintty window over the first one. > > > > (4) Hold ctrl key down. > > > > (5) Press 'd' key while holding ctrl key. The second mintty > > > > window will be closed. Keep ctrl key still hold down. > > > > (6) Now the first mintty window is focused. Then press 'd' key > > > > while holding ctrl key down. > > > > (7) The first mintty window will not logout but displays 'd'. > > > > > > > > I checked the pty and found the pty in the first mintty > > > > receives just 'd' but not Ctrl-D from mintty. In other words, > > > > fhandler_pty_master::write() is called with 'd'. So I suspect it > > > > might be a problem of mintty. Therefore, I tried old version > > > > of mintty. The results are: > > > > > > > > ... > > > > > > > Hi Takashi, > > > sorry this was attributed to pty, it is an issue of mintty I was aware > > > of which appeared in 3.7.2. > > > More precisely, it slipped in with > > > be73970877a99548aeeab60a2572ffb04b695066 "revise AltGr handling to > > > support flexible right-Alt+left-Ctrl combinations (#1266)", as a > > > trade-off for what I meant to be a final fix for control modifier > > > handling. I guess I hadn't considered it serious enough to reopen the > > > issue for another workaround. To be reconsidered... > > I just had a look into that commit and saw the description of a hidden > > option OldAltGrDetection right at the start. Looks like > > OldAltGrDetection=2 is a temporary workaround for the problem. What's > > the drawback of using it? > I've uploaded a fix to the github repository and tried to find an answer > to your question but couldn't yet... > Some background information: root cause of the trouble is Windows' > insane handling of the AltGr modifier and its failure to assign a > distinct virtual keycode to it. Instead it provides left-Control and > right-Alt key events, both with the same timestamp. That alone is a bit > tricky to detect as both Control and Alt are modifiers on their own. > Worse, software handling of AltGr detection or (in the case of remote > desktop software) generation often deviates from this scheme and even > Windows' own onscreen keyboard is buggy about this. Mintty has a number > of workarounds to handle that. Also, basically in a terminal emulator > the expectation is to handle all of Control, Alt etc and also their > combinations properly. For a example, on a keyboard where AltGr+q is > '@', Control+AltGr+q should be ^@, Alt+AltGr+q should be ESC @, and > Control+Alt+AltGr+q should be ESC ^@. All this is accomplished by > mintty. Together with the workarounds mentioned above, this is a > delicate area and I hope the fix found now interworks well with all such > software. > Thomas Thanks for your description. I'm running mintty with OldAltGrDetection=2 for a couple of days now and didn't have any problems. I assume the complicated detection cases you're working on don't show up in my workflow. Corinna -- 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
Re: [Ms-nfs41-client-devel] Fwd: Implementing mkfifo, mknod support with NFS_SPECFILE_FIFO and NFS_SPECFILE_SOCK?
On Feb 4 12:08, Corinna Vinschen via Cygwin wrote:
> $ cat > mk-dev-nfs.c < [...]
Copy/Paste error, try this one:
#include
#include
#include
typedef struct {
DWORD ReparseTag;
WORD ReparseDataLength;
WORD Reserved;
struct {
BYTE DataBuffer[1];
} GenericReparseBuffer;
struct {
ULONGLONG Type;
union {
struct {
ULONG Major;
ULONG Minor;
} Device;
WCHAR LnkBuffer[1];
};
} NfsReparseBuffer;
} MY_REPARSE_DATA_BUFFER, *MY_PREPARSE_DATA_BUFFER;
#define NFS_SPECFILE_LNK0x014B4E4CL
#define NFS_SPECFILE_CHR0x00524843L
#define NFS_SPECFILE_BLK0x004B4C42L
#define NFS_SPECFILE_FIFO 0x4F464946L
#define NFS_SPECFILE_SOCK 0x4B434F53L
int
main (int argc, char **argv)
{
HANDLE fh;
char buf[65536];
DWORD size_ret;
MY_PREPARSE_DATA_BUFFER rp;
if (argc < 3)
{
fprintf (stderr, "usage: %s b|c|f|s [major] [minor]\n", argv[0]);
return 1;
}
fh = CreateFile (argv[1],
GENERIC_WRITE,
0,
NULL,
CREATE_ALWAYS,
FILE_FLAG_BACKUP_SEMANTICS
| FILE_FLAG_OPEN_REPARSE_POINT,
NULL);
if (fh == INVALID_HANDLE_VALUE)
{
fprintf (stderr, "CreateFile: %d\n", GetLastError ());
return 1;
}
rp = (MY_PREPARSE_DATA_BUFFER) buf;
rp->ReparseTag = IO_REPARSE_TAG_NFS;
rp->ReparseDataLength = sizeof (ULONGLONG);
switch (argv[2][0])
{
case 'b':
case 'c':
if (argc != 5)
{
fprintf (stderr, "usage: %s b|c|f|s [major] [minor]\n",
argv[0]);
return 1;
}
rp->ReparseDataLength += 2 * sizeof (ULONG);
rp->NfsReparseBuffer.Type = argv[2][0] == 'b' ?
NFS_SPECFILE_BLK
: NFS_SPECFILE_CHR;
rp->NfsReparseBuffer.Device.Major = strtoul (argv[3], NULL, 0);
rp->NfsReparseBuffer.Device.Minor = strtoul (argv[4], NULL, 0);
break;
case 'f':
rp->NfsReparseBuffer.Type = NFS_SPECFILE_FIFO;
break;
case 's':
rp->NfsReparseBuffer.Type = NFS_SPECFILE_SOCK;
break;
}
if (! DeviceIoControl (fh, FSCTL_SET_REPARSE_POINT,
(LPVOID) buf,
REPARSE_GUID_DATA_BUFFER_HEADER_SIZE
+ rp->ReparseDataLength,
NULL, 0, &size_ret, NULL))
{
fprintf (stderr, "DeviceIoControl: %d\n", GetLastError ());
CloseHandle (fh);
DeleteFile (argv[1]);
return 1;
}
CloseHandle (fh);
return 0;
}
--
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
