Re: VS Code is missing a few characters when running launch task in Git Bash
On Tue, Jul 5, 2022 at 6:18 AM Takashi Yano wrote:
>
> On Mon, 4 Jul 2022 08:57:09 +0300
> Orgad Shaneh wrote:
> > Sure,
> >
> > Install VS Code and Node.JS.
> >
> > Clone this repository: https://github.com/orgads/cygtest
> >
> > Open the directory in VS Code and run (F5). Wait for it to finish,
> > then run again.
> >
> > I've noticed that even the first execution has some mistyped
> > characters (moved from ** to ##):
> >
> > waitForDeb**u**gge**r**
> > "exe**c**Path":"C:\\Program Fil**es**\\nodejs\\node.exe"
> > "autoAttachMod##urces##e":"always"
> >
> > And on the second run:
> > "inspecto**r**Ipc":".\\pipe\\node-cdp.9412-8.sock","##r##deferredMode":false
> >
> > $ /usr/bin/env 'NODE_OPTIONS=--require
> > "c:/Users/orgads/AppData/Local/Programs/Microsoft VS
> > Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
> > --inspect-publish-uid=http'
> > 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.9412-7.sock","deferredMode":false,"waitForDebgge":"","exePath":"C:\\Program
> > Fil\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachModurcese":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-c57206c2f20dca1d"}'
> > C:\\Program\ Files\\nodejs\\node.exe index.js
> > hi
> >
> > $ cd f:\\Projects\\cygtest ; /usr/bin/env 'NODE_OPTIONS=--require
> > "c:/Users/orgads/AppData/Local/Programs/Microsoft VS
> > Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
> > --inspect-publish-uid=http'
> > 'VSCODE_INSPECTOR_OPTIONS={"inspectoIpc":".\\pipe\\node-cdp.9412-8.sock","rdeferredMode":false,"waitForDebugger":"","execPath":"C:\\Program
> > Files\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-fab5a0d7b63917c7"}'
> > C:\\Program\ Files\\nodejs\\node.exe index.js
> > hi
>
> Thanks.
>
> Could you please test if the commit
> https://www.cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=521dfff143f9533533d161f37b73a92147c88e7c
> fixes the issue?
Yes, finally! Thank you very much! :)
You can test with the binary from here:
https://github.com/msys2/msys2-runtime/pull/96/checks
- Orgad
--
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: VS Code is missing a few characters when running launch task in Git Bash
Sure,
Install VS Code and Node.JS.
Clone this repository: https://github.com/orgads/cygtest
Open the directory in VS Code and run (F5). Wait for it to finish,
then run again.
I've noticed that even the first execution has some mistyped
characters (moved from ** to ##):
waitForDeb**u**gge**r**
"exe**c**Path":"C:\\Program Fil**es**\\nodejs\\node.exe"
"autoAttachMod##urces##e":"always"
And on the second run:
"inspecto**r**Ipc":".\\pipe\\node-cdp.9412-8.sock","##r##deferredMode":false
$ /usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.9412-7.sock","deferredMode":false,"waitForDebgge":"","exePath":"C:\\Program
Fil\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachModurcese":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-c57206c2f20dca1d"}'
C:\\Program\ Files\\nodejs\\node.exe index.js
hi
$ cd f:\\Projects\\cygtest ; /usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectoIpc":".\\pipe\\node-cdp.9412-8.sock","rdeferredMode":false,"waitForDebugger":"","execPath":"C:\\Program
Files\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-fab5a0d7b63917c7"}'
C:\\Program\ Files\\nodejs\\node.exe index.js
hi
On Mon, Jul 4, 2022 at 2:41 AM Takashi Yano wrote:
>
> On Sun, 3 Jul 2022 16:02:46 +0300
> Orgad Shaneh wrote:
> > On Sun, Jul 3, 2022 at 2:18 AM Takashi Yano
> > wrote:
> > >
> > > On Sat, 2 Jul 2022 08:34:06 +0900
> > > Takashi Yano wrote:
> > > > Thanks. I could reproduce the issue. I will submit a patch
> > > > for this issue shortly.
> > >
> > > Does the patch I pushd to cygwin-3_3-branch solve the
> > > VS Code issue?
> >
> >
> > Hi Takashi,
> >
> > Thank you.
> >
> > I think it is a bit better, and the paste issue is solved, but VS Code
> > still mistypes a few characters, and discards some quite long
> > sections.
>
> Perhaps, VS code issue is a separate issue from the issue of
> pasting long text.
>
> Could you please let me know the steps how to reproduce the
> issue?
>
> --
> Takashi Yano
--
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: VS Code is missing a few characters when running launch task in Git Bash
On Sun, Jul 3, 2022 at 2:18 AM Takashi Yano wrote:
>
> On Sat, 2 Jul 2022 08:34:06 +0900
> Takashi Yano wrote:
> > Thanks. I could reproduce the issue. I will submit a patch
> > for this issue shortly.
>
> Does the patch I pushd to cygwin-3_3-branch solve the
> VS Code issue?
Hi Takashi,
Thank you.
I think it is a bit better, and the paste issue is solved, but VS Code
still mistypes a few characters, and discards some quite long
sections.
Examples:
Good:
$ cd F:\\Projects\\VoiceAIConnector/session-manager/dist ;
/usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.2260-6.sock","deferredMode":false,"waitForDebugger":"","execPath":"C:\\Program
Files\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-92e9f97c5ea0c8b4"}'
C:\\Program\ Files\\nodejs\\node.exe
.\\..\\node_modules\\mocha\\bin\\_mocha --timeout 0 -r
tsconfig-paths/register test/unit-test/ssml.test.js
Bad 1:
All the part between the stars is gone (offsets are counted from the $
in the "good" command):
* Offset 187-209: ms-vsc**ode.js-debug/src/bootl**oader.bundle.js
* Offset 373-417: "execPath":"C:\\Progr**am Files\\nodejs\\node**.exe"
* Offset 603-625: C:\\Program\ Files\\nodejs\\node.e**xe
.\\..\\node_modules**\\mocha\\bin\\_mocha
$ cd F:\\Projects\\VoiceAIConnector/session-manager/dist ;
/usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscoader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.2260-6.sock","deferredMode":false,"waitForDebugger":"","execPath":"C:\\Progr.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-49cb84aaa44af289"}'
C:\\Program\ Files\\nodejs\\node.e\\mocha\\bin\\_mocha --timeout 0 -r
tsconfig-paths/register test/unit-test/ssml.test.js
Bad 2:
Same + b jumped from ** to ## (offset 568 -> 586 in this command):
\\mocha\\**in\\_mocha --timeo##b##ut 0 -r
$ cd F:\\Projects\\VoiceAIConnector/session-manager/dist ;
/usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscoader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.2260-7.sock","deferredMode":false,"waitForDebugger":"","execPath":"C:\\Progr.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-945eb8360380780f"}'
C:\\Program\ Files\\nodejs\\node.e\\mocha\\in\\_mocha --timeobut 0 -r
tsconfig-paths/register test/unit-test/ssml.test.js
Bad 3:
Same as 1 + s and e jumped from ** to ## (offsets 201 and 209 ->
229-230): ms-vscoader.bundle.j**" --insp**ct-publish-uid=http'##se##
$ cd F:\\Projects\\VoiceAIConnector/session-manager/dist ;
/usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscoader.bundle.j"
--inspct-publish-uid=http'se
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.2260-8.sock","deferredMode":false,"waitForDebugger":"","execPath":"C:\\Progr.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-dcc14f60d807e31f"}'
C:\\Program\ Files\\nodejs\\node.e\\mocha\\bin\\_mocha --timeout 0 -r
tsconfig-paths/register test/unit-test/loader.js
The binary was built here:
https://github.com/msys2/msys2-runtime/pull/96/checks (Artifacts ->
install).
- Orgad
--
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: VS Code is missing a few characters when running launch task in Git Bash
On Fri, Jul 1, 2022 at 1:02 AM Orgad Shaneh wrote: > > On Sun, May 29, 2022 at 9:00 AM Orgad Shaneh wrote: > > > > On Fri, May 27, 2022 at 3:43 PM Takashi Yano > > wrote: > > > > > > On Fri, 27 May 2022 15:22:23 +0300 > > > Orgad Shaneh wrote: > > > > On Fri, May 27, 2022 at 11:06 AM Orgad Shaneh wrote: > > > > > > > > > > On Fri, May 27, 2022 at 10:59 AM Adam Dinwoodie > > > > > wrote: > > > > > > > > > > > > On Fri, May 27, 2022 at 10:15:18AM +0300, Orgad Shaneh wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm using Git Bash as the default terminal in VS Code. Using Git > > > > > > > for > > > > > > > Windows 2.36.1 with the latest runtime, based on cygwin 3.5.0. > > > > > > Do you mean cygwin 3.3.5? > > > > Yes, of course. > > > > > Two questions: > > > 1) Is the terminal in VS Code runs on console or pty? (What does > > > 'tty' command says?) > > > > /dev/cons0 > > > > I guess this means console? > > > > > 2) If the terminal runs on pty, did you try both with and without > > > 'disable_pcon'? > > > > It's console. > > I might have found a way to reproduce on Cygwin (3.3.5). I can > reproduce this on both Windows Terminal and the native console (Just > running Cygwin.bat). > > Open Cygwin terminal. Paste the following text (can either be with > Shift-Ins in Windows Terminal, or right-click on native console): > > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > > The output looks like this. Notice that after 1024 characters, it > starts to garble: > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz > abcdefghijklmnopqrs
Re: VS Code is missing a few characters when running launch task in Git Bash
On Sun, May 29, 2022 at 9:00 AM Orgad Shaneh wrote: > > On Fri, May 27, 2022 at 3:43 PM Takashi Yano wrote: > > > > On Fri, 27 May 2022 15:22:23 +0300 > > Orgad Shaneh wrote: > > > On Fri, May 27, 2022 at 11:06 AM Orgad Shaneh wrote: > > > > > > > > On Fri, May 27, 2022 at 10:59 AM Adam Dinwoodie > > > > wrote: > > > > > > > > > > On Fri, May 27, 2022 at 10:15:18AM +0300, Orgad Shaneh wrote: > > > > > > Hi, > > > > > > > > > > > > I'm using Git Bash as the default terminal in VS Code. Using Git for > > > > > > Windows 2.36.1 with the latest runtime, based on cygwin 3.5.0. > > > > Do you mean cygwin 3.3.5? > > Yes, of course. > > > Two questions: > > 1) Is the terminal in VS Code runs on console or pty? (What does > > 'tty' command says?) > > /dev/cons0 > > I guess this means console? > > > 2) If the terminal runs on pty, did you try both with and without > > 'disable_pcon'? > > It's console. I might have found a way to reproduce on Cygwin (3.3.5). I can reproduce this on both Windows Terminal and the native console (Just running Cygwin.bat). Open Cygwin terminal. Paste the following text (can either be with Shift-Ins in Windows Terminal, or right-click on native console): abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz The output looks like this. Notice that after 1024 characters, it starts to garble: abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqr
Re: VS Code is missing a few characters when running launch task in Git Bash
On Fri, May 27, 2022 at 3:43 PM Takashi Yano wrote: > > On Fri, 27 May 2022 15:22:23 +0300 > Orgad Shaneh wrote: > > On Fri, May 27, 2022 at 11:06 AM Orgad Shaneh wrote: > > > > > > On Fri, May 27, 2022 at 10:59 AM Adam Dinwoodie > > > wrote: > > > > > > > > On Fri, May 27, 2022 at 10:15:18AM +0300, Orgad Shaneh wrote: > > > > > Hi, > > > > > > > > > > I'm using Git Bash as the default terminal in VS Code. Using Git for > > > > > Windows 2.36.1 with the latest runtime, based on cygwin 3.5.0. > > Do you mean cygwin 3.3.5? Yes, of course. > Two questions: > 1) Is the terminal in VS Code runs on console or pty? (What does > 'tty' command says?) /dev/cons0 I guess this means console? > 2) If the terminal runs on pty, did you try both with and without > 'disable_pcon'? It's console. - Orgad -- 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: VS Code is missing a few characters when running launch task in Git Bash
On Fri, May 27, 2022 at 11:06 AM Orgad Shaneh wrote: > > On Fri, May 27, 2022 at 10:59 AM Adam Dinwoodie wrote: > > > > On Fri, May 27, 2022 at 10:15:18AM +0300, Orgad Shaneh wrote: > > > Hi, > > > > > > I'm using Git Bash as the default terminal in VS Code. Using Git for > > > Windows 2.36.1 with the latest runtime, based on cygwin 3.5.0. > > > > Hi Orgad, > > > > Git for Windows and Git Bash are based in part on Cygwin, but they're > > downstream projects that aren't supported by the Cygwin mailing list: > > the Git for Windows folks have made changes to the Cygwin code for their > > use case, which they're 100% welcome to do, but which mean the folk on > > the Cygwin mailing list just don't have the knowledge or experience to > > help. > > > > If you can show problems with Cygwin, be that with the Cygwin DLL, > > Cygwin's Bash or Cygwin's Git, the Cygwin mailing lists are definitely > > the right place to ask for help. But unless you can demonstrate the > > problem using Cygwin packages without any downstream modifications, this > > list isn't going to be able to help you. > > > > Based on https://gitforwindows.org/ I suspect your best bet for getting > > help here is either (a) asking on the Git for Windows mailing list at > > https://groups.google.com/g/git-for-windows, or (b) raising an issue at > > https://github.com/git-for-windows/git. > > Hi, > > Thank you. > > I reported several issues related to type-ahead (all of them happened > in MSYS, and some of them were not reproducible in cygwin), and they > were identified and fixed by @Takashi Yano in cygwin runtime. > > Some issues are hard to reproduce, and I can't always reproduce them > on cygwin, but that doesn't mean the root cause is in MSYS patches. > > Anyway, I'll try to reproduce with cygwin and report back. It doesn't reproduce with Cygwin. I'll report on git-for-windows, but like I said, I doubt this relates to MSYS changes. - Orgad -- 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: VS Code is missing a few characters when running launch task in Git Bash
On Fri, May 27, 2022 at 10:59 AM Adam Dinwoodie wrote: > > On Fri, May 27, 2022 at 10:15:18AM +0300, Orgad Shaneh wrote: > > Hi, > > > > I'm using Git Bash as the default terminal in VS Code. Using Git for > > Windows 2.36.1 with the latest runtime, based on cygwin 3.5.0. > > Hi Orgad, > > Git for Windows and Git Bash are based in part on Cygwin, but they're > downstream projects that aren't supported by the Cygwin mailing list: > the Git for Windows folks have made changes to the Cygwin code for their > use case, which they're 100% welcome to do, but which mean the folk on > the Cygwin mailing list just don't have the knowledge or experience to > help. > > If you can show problems with Cygwin, be that with the Cygwin DLL, > Cygwin's Bash or Cygwin's Git, the Cygwin mailing lists are definitely > the right place to ask for help. But unless you can demonstrate the > problem using Cygwin packages without any downstream modifications, this > list isn't going to be able to help you. > > Based on https://gitforwindows.org/ I suspect your best bet for getting > help here is either (a) asking on the Git for Windows mailing list at > https://groups.google.com/g/git-for-windows, or (b) raising an issue at > https://github.com/git-for-windows/git. Hi, Thank you. I reported several issues related to type-ahead (all of them happened in MSYS, and some of them were not reproducible in cygwin), and they were identified and fixed by @Takashi Yano in cygwin runtime. Some issues are hard to reproduce, and I can't always reproduce them on cygwin, but that doesn't mean the root cause is in MSYS patches. Anyway, I'll try to reproduce with cygwin and report back. - Orgad -- 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
VS Code is missing a few characters when running launch task in Git Bash
Hi,
I'm using Git Bash as the default terminal in VS Code. Using Git for
Windows 2.36.1 with the latest runtime, based on cygwin 3.5.0.
I have a launch configuration that executes a Node.JS application in
the integrated terminal.
When I launch it for the first time, it spawns a new terminal and
works correctly (most of the time), but when the terminal is being
reused (and sometimes also for a new terminal), the command is missing
a few characters, so it fails.
These are the commands that are executed. The first one works, the
second one fails.
/usr/bin/env 'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.17916-22.sock","deferredMode":false,"waitForDebugger":"","execPath":"C:\\Program
Files\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-c34e93d552518e0a"}'
"C:\\Program Files\\nodejs\\node.exe"
.\\..\\node_modules\\mocha\\bin\\_mocha "--timeout " -r
tsconfig-paths/register my-app.js
cd F:\\Projects\\MyFailingProject/prjct-directory/dist ; /usr/bin/env
'NODE_OPTIONS=--require
"c:/Users/orgads/AppData/Local/Programs/Microsoft VS
Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js"
--inspect-publish-uid=http'
'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":".\\pipe\\node-cdp.17916-23.ock","dferedMode":fale,"waitForDebugger":"","execPath":"C:\\Program
Files\\nodejs\\node.exe","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"C:\\Users\\orgads\\AppData\\Local\\Temp\\node-debug-callback-cc2a4594562280e4"}'
"C:\\Program Files\\nodejs\\node.exe"
.\\..\\node_modules\\mocha\\bin\\_mocha "--timeout " -r
tsconfig-pathsregister my-app.js
The follwing characters are missing (marking them with **):
"inspectorIpc":".\\pipe\\node-cdp.17916-23.**s**ock","d**e**fe**r**redMode":fal**s**e
... -r tsconfig-paths**/**register my-app.js
Notice there is one block (starts on char 325), which is missing 4
characters (325, 332, 334, 346), and another character close to the
end of the line.
Another execution was missing:
"execPath":"C:\\Program
File**s**\\nod**e**js\\node.exe","onlyEnt**r**ypoint":fal**s**e,"autoAttachMode":"
and the same slash.
The terminal also auto-types the missing characters (sers/) in the
next line, without executing it (waiting for Enter). The characters
are the same in both executions (sers/), only taken from different
locations.
This issue started a few months ago. IIRC it was around the same time
I reported the misordered characters issue (last February), but I
can't tell for sure.
With 3.5.0, it happens less than before, but I still hit it once in a while.
Any idea what can cause this?
- Orgad
--
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: mintty crashes on Windows 7
On Sun, May 8, 2022 at 2:09 PM Takashi Yano wrote: > I have pushed two patches to cygwin-3_3-branch. I am not sure > why, but the issue (bash with readline crash) seems to disappear. > > Could you please try? It no longer crashes with these fixes. Thanks! - Orgad -- 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: mintty crashes on Windows 7
On Fri, May 6, 2022 at 1:49 AM Takashi Yano wrote: > > Only bash in msys2 package fails. > > I identified the difference which causes the issue > between bash built from original source and msys2 bash. > > If --enable-readline and --with-installed-readline is specified > to configure, the problem causes even with bash built from original > source. > > Also, removing --with-installed-readline from configure and removing > READLINE_LDFLAGS= from make in PKGBUILD of MSYS2 bash package solves > the issue. > > So it seems to be a readline problem, not a bug in bash itself. Adding @Johannes Schindelin to the loop. Thanks for your investigation so far. So how do we proceed, assuming MSYS project does want to use the installed readline? I checked the readline PKGBUILD, and it only has very basic patches, none of them looks suspicious. Is (external) readline not used in cygwin/bash? Do you suggest that there's a bug in readline, that your change in the runtime uncovered? Or is it the other way around? What might we break if we revert the part I referenced earlier in fhandler_tty.cc? - Orgad -- 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: mintty crashes on Windows 7
On Wed, May 4, 2022 at 2:16 PM Takashi Yano wrote:
>
> > Reduced the revert to this:
> > @@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
> > code does not work as expected because it calls Win32
> > API directly rather than cygwin read()/write(). Due to
> > this behaviour, protection based on attach_mutex does
> > not take effect. */
> > get_ttyp ()->need_invisible_console = true;
> > - else if (_major (myself->ctty) != DEV_CONS_MAJOR
> > -&& (!get_ttyp ()->invisible_console_pid
> > -|| !pinfo (get_ttyp ()->invisible_console_pid)))
> > -/* Create a new invisible console for each pty to isolate
> > - CTRL_C_EVENTs between ptys. */
> > -get_ttyp ()->need_invisible_console = true;
> >else
> > {
> >acquire_attach_mutex (mutex_timeout);
> >fhandler_console::need_invisible ();
> >release_attach_mutex ();
>
> A few things about this.
>
> 1) bash exits with exit code 127 for 'mintty bash'
> 2) 'mintty bash' does not work, but 'mintty ash' and 'mintty tcsh' work.
Right. mintty dash also works.
Notice that I did *not* set enable_pcon (not supported on Win7 anyway).
- Orgad
--
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: mintty crashes on Windows 7
On Wed, May 4, 2022 at 12:33 PM Orgad Shaneh wrote:
>
> On Tue, May 3, 2022 at 7:10 PM Takashi Yano wrote:
> >
> > On Tue, 3 May 2022 18:52:28 +0300
> > Orgad Shaneh wrote:
> > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano
> > > wrote:
> > > >
> > > > On Tue, 3 May 2022 14:47:17 +0300
> > > > Orgad Shaneh wrote:
> > > > > Hi,
> > > > >
> > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
> > > > >
> > > > > Tested in MSYS2 on merge-3.3 branch from
> > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of
> > > > > cygwin-3_3-branch as of today (05827d2df8).
> > > > >
> > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch.
> > > > Is this MSYS2 specific problem?
> > >
> > > You're right. I can't reproduce either. Only in my MSYS branch.
> > >
> > > Can you give me some guidance how to debug it?
> >
> > If you could identify which commit causes the issue, It would help.
>
> 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit
> commit 0e1847fb87f5306cda6c022540560c5926627ae1
> Author: Takashi Yano
> Date: Mon Feb 28 20:25:09 2022 +0900
>
> Cygwin: pty: Isolate CTRL_C_EVENTs between ptys.
>
> - With this patch, unique invisible consoles are created for each pty
> to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C
> handling in fhandler_termios::process_sigs() for non-cygwin apps
> started in pty if the pseudo console is disabled.
>
> winsup/cygwin/fhandler_termios.cc | 6 ++
> winsup/cygwin/fhandler_tty.cc | 17 +
> winsup/cygwin/tty.cc | 2 ++
> 3 files changed, 21 insertions(+), 4 deletions(-)
>
> I tried reverting this commit, and it fixed the crash indeed.
>
> - Orgad
Reduced the revert to this:
@@ -979,16 +979,10 @@ fhandler_pty_slave::open (int flags, mode_t)
code does not work as expected because it calls Win32
API directly rather than cygwin read()/write(). Due to
this behaviour, protection based on attach_mutex does
not take effect. */
get_ttyp ()->need_invisible_console = true;
- else if (_major (myself->ctty) != DEV_CONS_MAJOR
-&& (!get_ttyp ()->invisible_console_pid
-|| !pinfo (get_ttyp ()->invisible_console_pid)))
-/* Create a new invisible console for each pty to isolate
- CTRL_C_EVENTs between ptys. */
-get_ttyp ()->need_invisible_console = true;
else
{
acquire_attach_mutex (mutex_timeout);
fhandler_console::need_invisible ();
release_attach_mutex ();
- Orgad
--
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: mintty crashes on Windows 7
On Tue, May 3, 2022 at 7:10 PM Takashi Yano wrote: > > On Tue, 3 May 2022 18:52:28 +0300 > Orgad Shaneh wrote: > > On Tue, May 3, 2022 at 6:23 PM Takashi Yano > > wrote: > > > > > > On Tue, 3 May 2022 14:47:17 +0300 > > > Orgad Shaneh wrote: > > > > Hi, > > > > > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch. > > > > > > > > Tested in MSYS2 on merge-3.3 branch from > > > > https://github.com/orgads/msys2-runtime-1. It includes the tip of > > > > cygwin-3_3-branch as of today (05827d2df8). > > > > > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch. > > > Is this MSYS2 specific problem? > > > > You're right. I can't reproduce either. Only in my MSYS branch. > > > > Can you give me some guidance how to debug it? > > If you could identify which commit causes the issue, It would help. 0e1847fb87f5306cda6c022540560c5926627ae1 is the first bad commit commit 0e1847fb87f5306cda6c022540560c5926627ae1 Author: Takashi Yano Date: Mon Feb 28 20:25:09 2022 +0900 Cygwin: pty: Isolate CTRL_C_EVENTs between ptys. - With this patch, unique invisible consoles are created for each pty to isolate CTRL_C_EVENTs between ptys. This is necessary by Ctrl-C handling in fhandler_termios::process_sigs() for non-cygwin apps started in pty if the pseudo console is disabled. winsup/cygwin/fhandler_termios.cc | 6 ++ winsup/cygwin/fhandler_tty.cc | 17 + winsup/cygwin/tty.cc | 2 ++ 3 files changed, 21 insertions(+), 4 deletions(-) I tried reverting this commit, and it fixed the crash indeed. - Orgad -- 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: mintty crashes on Windows 7
On Tue, May 3, 2022 at 6:23 PM Takashi Yano wrote: > > On Tue, 3 May 2022 14:47:17 +0300 > Orgad Shaneh wrote: > > Hi, > > > > Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch. > > > > Tested in MSYS2 on merge-3.3 branch from > > https://github.com/orgads/msys2-runtime-1. It includes the tip of > > cygwin-3_3-branch as of today (05827d2df8). > > > I cannot reproduce this with cygwin git head of cygwin-3_3-branch. > Is this MSYS2 specific problem? You're right. I can't reproduce either. Only in my MSYS branch. Can you give me some guidance how to debug it? - Orgad -- 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
mintty crashes on Windows 7
Hi,
Running `mintty ./bash` crashes on Windows 7 on cygwin-3_3-branch.
Tested in MSYS2 on merge-3.3 branch from
https://github.com/orgads/msys2-runtime-1. It includes the tip of
cygwin-3_3-branch as of today (05827d2df8).
Steps to reproduce:
1. Start cmd.exe
2. cd \usr\bin
3. mintty ./bash
GDB trace attached. Simplified form:
1 ntdll!KiRaiseUserExceptionDispatcher 0x7791b5ba
2 KERNELBASE!CloseHandle 0x7feffb31863
3 KERNEL32!CloseHandle 0x776b14f1
4 fhandler_base::close fhandler.cc 1217 0x1800682db
5 fhandler_pipe::close fhandler_pipe.cc 685 0x18009069a
6 fhandler_base::close_with_arch fhandler.cc 1193 0x18006c7d5
7 close_all_files syscalls.cc 102 0x18014548f
8 do_exit dcrt0.cc 1200 0x180048213
9 _exitdcrt0.cc 1317 0x1800483ef
10 exit exit.c 64 0x1801b3bdd
11 cygwin_exit dcrt0.cc 1311 0x1800483d3
12 _sigfe sigfe.s 35 0x18019593b
13 ??
Thread 5 (Thread 6896.0x1eb8 "waitproc"):
#0 0x7791980a in ntdll!ZwReadFile () from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x07feffb31a6a in ReadFile () from C:\Windows\system32\KernelBase.dll
No symbol table info available.
#2 0x776a0599 in ReadFile () from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3 0x00018010ca04 in proc_waiter (arg=) at
../../../../winsup/cygwin/pinfo.cc:1214
nb = 0
buf = 0 '\000'
vchild = { = {h = 0x228, hProcess = 0x22c, rd_proc_pipe
= 0x220}, destroy = false, winpid_hdl = 0x0, procinfo = 0x3a, waiter_ready
= false, wait_thread = 0x180238898 }
si = {si_signo = 20, si_code = 28, si_pid = 502, si_uid = 0, si_errno =
0, {__pad = {0 }, _si_commune = {_si_code = 0,
_si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0,
{{_si_fd = 0, _si_flags = 0}, _si_pipe_unique_id = 0, _si_str = 0x0}},
{{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0,
sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0,
si_stime = 0}, si_addr = 0x0, {__pad2 = {0 }, si_cyg = 0x0}}}
pid = 502
its_me = false
__PRETTY_FUNCTION__ = "DWORD proc_waiter(void*)"
#4 0x000180046583 in cygthread::callfunc (this=this@entry=0x180238898
, issimplestub=issimplestub@entry=false) at
../../../../winsup/cygwin/cygthread.cc:48
pass_arg =
#5 0x000180046b46 in cygthread::stub (arg=arg@entry=0x180238898
) at ../../../../winsup/cygwin/cygthread.cc:91
notify =
info = 0x180238898
__PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#6 0x000180047716 in _cygtls::call2 (this=0x24ace00, func=0x180046ac0
, arg=0x180238898 ,
buf=buf@entry=0x24acd50) at ../../../../winsup/cygwin/cygtls.cc:40
res =
#7 0x0001800477c4 in _cygtls::call (func=, arg=) at ../../../../winsup/cygwin/cygtls.cc:27
buf = '\000' ,
"?M#\200\001\000\000\000\220N#\200\001\000\000\000HO#\200\001", '\000' , "\377\377\377\377\000\000\000\000\220Y\033\200\001", '\000' ,
"\001\000\000\000\000\000\000\000\016\063\315?4\022m?\336?\005\000\v", '\000'
, "\003\000\000\000\000\000\000\000?M#\200\001", '\000'
, "\200\326?J\002", '\000' , "\002",
'\000' , "?\036", '\000' ,
"\230\210#\200\001", '\000' , "X?J\002", '\000' , "?\027c\307", '\000' , "\nTjw", '\000' ,
"\037\000\004\033\000\000\000\000\020\004\000\000\000\000\000\000\210\371?<\000\000\000\000\000\001\000\000\000\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000??\230w\000\000\000\000\212?<\000\000\000\000\000??<\000\000\000\000\000\200\371?<",
'\000' ,
"\001\000\000\000\000\000\000\000D\000\000\000\000\000\000\000 #", '\000'
,
"\004\000\000\000\003\300\002\005\000\000\000\000\000\000\000\000\200\371?<\000\000\000\000\000\220?<\000\000\000\000\000\177\000\000\000\000\000\000\000\220?<",
'\000' , "D", '\000' , "\177\000\000\000
#", '\000' , "D", '\000' , "\020\004",
'\000' ,
"\220?<\000\000\000\000\000\060\000\000\000\000\000\000\000\060\002;", '\000'
, " 6\002", '\000' ,
"t\002;\000\000\000\000\000\060\002;\000\000\000\000\000\177", '\000' , "\060\002;", '\000' , "d#\004C", '\000' , "\002\000\004\006", '\000' , "(1?w", '\000'
,
";\000\000\000\000\000\000\000;\000\000\000\000\000\020\004", '\000' ,
"\234{\215w\000\000\000\000\000\000;\000\000\000\000\000k\001,P\000\000\000\000\020\004\000\000\000\000\000\000@\004",
'\000' ...
protect =
#8 0x776a556d in KERNEL32!BaseThreadInitThunk () from
C:\Windows\system32\kernel32.dll
No symbol table info available.
#9 0x7790372d in ntdll!RtlUserThreadStart () from
C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#10 0x
Re: Typed characters are mis-ordered when CPU usage is high
On Fri, Mar 18, 2022 at 2:15 PM Takashi Yano wrote: > > On Fri, 18 Mar 2022 13:21:00 +0200 > Orgad Shaneh wrote: > > > Git for Windows > > > > Were you able to reproduce? > > > > I found an easier way to reproduce, which works almost every time. > > > > It still happens only on Git Bash, and not on MSYS2 MINGW64, although > > I use the same dll in both. I have no idea why there's a difference. > > :/ > > > > I run Windows Terminal, but it reproduces also in cmd, as you tried. > > > > 1. In Control Panel -> Keyboard, set Repeat delay to shortest and > > Repeat rate to fastest. > > 2. In msys2-runtime run git fetch > > 3. Type git and press and hold q > > Thanks. I can reproduce the issue. I think I found the cause. > The two unexpected things happen. > > (1) wVirtualKeyCode and wVirtualScanCode of readback key event may > be null'ed even if they are not zero on WriteConsoleInputW(). > Therefore, memcmp() report the event is not equal. > (2) WriteConsoleInputW() may not be atomic. The event sequence which > is written by WriteConsoleInputW() may be inserted by key input > in the middle of the sequence. > > A patch for these issues is attached. Could you please test? > > -- > Takashi Yano Awesome, looks good now. Thank you very much! Hope this is the last bit :) - Orgad -- 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: Typed characters are mis-ordered when CPU usage is high
On Fri, Mar 18, 2022 at 8:32 AM Orgad Shaneh wrote: > > On Fri, Mar 18, 2022, 8:31 AM Takashi Yano wrote: >> >> On Fri, 18 Mar 2022 07:57:27 +0200 >> Orgad Shaneh wrote: >> > I'm using the dll that was built here: >> > https://github.com/git-for-windows/msys2-runtime/actions/runs/218081 >> > for my PR: https://github.com/git-for-windows/msys2-runtime/pull/43 >> > >> > I can reproduce in msys2-runtime repo, but it's quite hard. Try this: >> > 1. git fetch >> > 2. While it is running, write git and then very quickly type >> > ququququququququququququququququ until the prompt appears. >> > >> > Sometimes you'll get q or u before git. >> >> Do you run git in Git for Windows? or msys2 git? > > > Git for Windows Were you able to reproduce? I found an easier way to reproduce, which works almost every time. It still happens only on Git Bash, and not on MSYS2 MINGW64, although I use the same dll in both. I have no idea why there's a difference. :/ I run Windows Terminal, but it reproduces also in cmd, as you tried. 1. In Control Panel -> Keyboard, set Repeat delay to shortest and Repeat rate to fastest. 2. In msys2-runtime run git fetch 3. Type git and press and hold q - Orgad -- 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: Typed characters are mis-ordered when CPU usage is high
On Fri, Mar 18, 2022, 8:31 AM Takashi Yano wrote: > On Fri, 18 Mar 2022 07:57:27 +0200 > Orgad Shaneh wrote: > > I'm using the dll that was built here: > > https://github.com/git-for-windows/msys2-runtime/actions/runs/218081 > > for my PR: https://github.com/git-for-windows/msys2-runtime/pull/43 > > > > I can reproduce in msys2-runtime repo, but it's quite hard. Try this: > > 1. git fetch > > 2. While it is running, write git and then very quickly type > > ququququququququququququququququ until the prompt appears. > > > > Sometimes you'll get q or u before git. > > Do you run git in Git for Windows? or msys2 git? > Git for Windows > -- 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: Typed characters are mis-ordered when CPU usage is high
On Fri, Mar 18, 2022 at 7:22 AM Takashi Yano wrote: > > On Fri, 18 Mar 2022 13:23:35 +0900 > Takashi Yano wrote: > > > On Thu, 17 Mar 2022 20:40:15 +0200 > > Orgad Shaneh wrote: > > > On Fri, Mar 11, 2022 at 11:36 PM Takashi Yano > > > wrote: > > > > I looked into this problem and found the cause. > > > > This seems to be due to a bug of fsync(). Cygwin's fsync() > > > > flushes the console input buffer unlike linux. > > > > > > > > I will propose a patch for this issue. > > > > > > > > -- > > > > Takashi Yano > > > > > > Thank you very much. Looks better now. > > > > > > I'm sorry for nudging, but on msys2 I still get frequent mistypes when > > > typing fast. > > > > > > I (still) don't have a consistent reproduction, but if I get it > > > correctly, it looks like one or more characters I type right when the > > > prompt appears show up before the buffered characters. > > > > > > For instance, I run git fetch, and while it is running I type git > > > status, *sometimes* 1-2 characters "pop" to the left, so I get > > > something like tgit satus. > > > > > > I wasn't able to reproduce it with cygwin, but on msys2 (with cygwin > > > 3.3 branch merged in) it happens to me all the time :/ > > > > Thansk for the report. > > > > I cloned the msys2-runtime repository from > > https://github.com/msys2/msys2-runtime > > and applied patches in cygwin-3_3-branch against msys2-3_3_4-release > > branch. The patches applied are listed in cygwin-3_3-branch-merged.log > > attached. A few patches, which are not actually in cygwin-3_3-branch, > > are also applied just for avoiding conflict easily. > > > > However, I cannot reproduce your problem. Have you surely applied the > > following patches especially important for this issue? > > > > Could you please also check if the code of cons_master_thread() in > > fhandler_console.cc exactly matches with cons_master_thread.cc attached? > > I also tried merge-3.3 branch from > https://github.com/orgads/msys2-runtime-1 (perhaps it's your repository), > and confirmed it works without the issue. What is the difference? > > I tried the following steps. > > 1) Start cmd.exe (command prompt). > 2) Run \msys64\usr\bin\bash -l > 3) cd msys2-runtime > 4) git fetch > 5) Quickly type "git status" before the shell prompt is shown. > 6) Repeat 4) and 5) many times. I'm using the dll that was built here: https://github.com/git-for-windows/msys2-runtime/actions/runs/218081 for my PR: https://github.com/git-for-windows/msys2-runtime/pull/43 I can reproduce in msys2-runtime repo, but it's quite hard. Try this: 1. git fetch 2. While it is running, write git and then very quickly type ququququququququququququququququ until the prompt appears. Sometimes you'll get q or u before git. - Orgad -- 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: Typed characters are mis-ordered when CPU usage is high
On Fri, Mar 11, 2022 at 11:36 PM Takashi Yano wrote: > I looked into this problem and found the cause. > This seems to be due to a bug of fsync(). Cygwin's fsync() > flushes the console input buffer unlike linux. > > I will propose a patch for this issue. > > -- > Takashi Yano Thank you very much. Looks better now. I'm sorry for nudging, but on msys2 I still get frequent mistypes when typing fast. I (still) don't have a consistent reproduction, but if I get it correctly, it looks like one or more characters I type right when the prompt appears show up before the buffered characters. For instance, I run git fetch, and while it is running I type git status, *sometimes* 1-2 characters "pop" to the left, so I get something like tgit satus. I wasn't able to reproduce it with cygwin, but on msys2 (with cygwin 3.3 branch merged in) it happens to me all the time :/ - Orgad -- 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: Typed characters are mis-ordered when CPU usage is high
On Thu, Mar 3, 2022 at 2:02 AM Takashi Yano wrote: > > On Wed, 2 Mar 2022 22:13:30 +0200 > Orgad Shaneh wrote: > > On Wed, Mar 2, 2022 at 1:13 AM Takashi Yano > > wrote: > > > > > > Hi Orgad, > > > > > > On Sun, 27 Feb 2022 23:53:03 +0900 > > > Takashi Yano wrote: > > > > On Sun, 27 Feb 2022 16:39:24 +0200 > > > > Orgad Shaneh wrote: > > > > > Hi, > > > > > > > > > > I'm using cygwin runtime 3.3.4-2. > > > > > > > > > > When a foreground job is running, and the general CPU usage of the > > > > > machine is high, characters are mis-ordered. > > > > > > > > > > To reproduce, I use this script to produce load: > > > > > #!/bin/sh > > > > > > > > > > for i in $(seq $(nproc)); do > > > > > while true; do :; done & > > > > > done > > > > > wait > > > > > > > > > > Run it in the background, then run a long foreground job, and while it > > > > > is running, type something. > > > > > > > > > > Example: > > > > > $ spin.sh & > > > > > $ sleep 3 # While it is running, I quickly typed git status > > > > > $ sigt tatus > > > > > > > > > > This reproduces on Windows Terminal and on cmd (Cygwin.bat) > > > > > > > > Thanks for the report. > > > > > > > > I think this is due to a bug which I recently fixed. > > > > https://cygwin.com/pipermail/cygwin-patches/2022q1/011791.html > > > > > > Now, new developer snapshot is ready: https://cygwin.com/snapshots/ > > > Please try. > > > > Tested. Looks much better. Thanks! > > Thanks for testing. But what do you mean by 'better'? > Do you mean that the problem still happens in lower probability? After using it on more scenarios (3.3 branch), I see have strange problems. For example, if I run git log -1 and immediately type, my input is lost until the prompt appears again. It doesn't happen with other commands like git status, I'm not sure why there's a difference. - Orgad -- 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
Missing package in the FAQ doc
Hi, On How do I build Cygwin on my own[1], there is a list of packages that are required for building cygwin. The "patch" package should be added to the list. And I also needed to install cocom for shilka. Had this error: ../../../../winsup/cygwin/gendevices ../../../../winsup/cygwin/devices.in ../../../../winsup/cygwin/devices.cc ../../../../winsup/cygwin/gendevices: shilka command missing? - No such file or directory make[4]: *** [Makefile:2889: ../../../../winsup/cygwin/devices.cc] Error 2 According to the FAQ, it is only required "If you change a certain core part of Cygwin, namely the layout of the Cygwin TLS area". And last thing - I didn't install xmlto and the other doc tools, and make failed. So either configure should check for their existence and not build doc if they don't exist, or at least suggest running make -k if these tools are not installed. Thanks. [1] https://cygwin.com/faq.html#faq.programming.building-cygwin -- 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: Typed characters are mis-ordered when CPU usage is high
On Thu, Mar 3, 2022, 2:02 AM Takashi Yano wrote: > On Wed, 2 Mar 2022 22:13:30 +0200 > Orgad Shaneh wrote: > > On Wed, Mar 2, 2022 at 1:13 AM Takashi Yano > wrote: > > > > > > > Now, new developer snapshot is ready: https://cygwin.com/snapshots/ > > > Please try. > > > > Tested. Looks much better. Thanks! > > Thanks for testing. But what do you mean by 'better'? > Do you mean that the problem still happens in lower probability? > > No, it's fixed. > > > Is a release planned soon? > > This fix was also applied in cygwin-3_3-branch, so the next > release (probably 3.3.5) will come with the fix. > > I understand. I meant to ask if there is a planned schedule for the next > release. > > - Orgad -- 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: Typed characters are mis-ordered when CPU usage is high
On Wed, Mar 2, 2022 at 1:13 AM Takashi Yano wrote: > > Hi Orgad, > > On Sun, 27 Feb 2022 23:53:03 +0900 > Takashi Yano wrote: > > On Sun, 27 Feb 2022 16:39:24 +0200 > > Orgad Shaneh wrote: > > > Hi, > > > > > > I'm using cygwin runtime 3.3.4-2. > > > > > > When a foreground job is running, and the general CPU usage of the > > > machine is high, characters are mis-ordered. > > > > > > To reproduce, I use this script to produce load: > > > #!/bin/sh > > > > > > for i in $(seq $(nproc)); do > > > while true; do :; done & > > > done > > > wait > > > > > > Run it in the background, then run a long foreground job, and while it > > > is running, type something. > > > > > > Example: > > > $ spin.sh & > > > $ sleep 3 # While it is running, I quickly typed git status > > > $ sigt tatus > > > > > > This reproduces on Windows Terminal and on cmd (Cygwin.bat) > > > > Thanks for the report. > > > > I think this is due to a bug which I recently fixed. > > https://cygwin.com/pipermail/cygwin-patches/2022q1/011791.html > > Now, new developer snapshot is ready: https://cygwin.com/snapshots/ > Please try. Tested. Looks much better. Thanks! Is a release planned soon? - Orgad -- 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
Typed characters are mis-ordered when CPU usage is high
Hi, I'm using cygwin runtime 3.3.4-2. When a foreground job is running, and the general CPU usage of the machine is high, characters are mis-ordered. To reproduce, I use this script to produce load: #!/bin/sh for i in $(seq $(nproc)); do while true; do :; done & done wait Run it in the background, then run a long foreground job, and while it is running, type something. Example: $ spin.sh & $ sleep 3 # While it is running, I quickly typed git status $ sigt tatus This reproduces on Windows Terminal and on cmd (Cygwin.bat) Please CC me on replies, as I'm not registered to the mailing list. Thanks, - Orgad -- 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: Console output hangs in the middle of a line
On Sun, Feb 20, 2022 at 4:34 PM Takashi Yano wrote: > > On Sun, 20 Feb 2022 23:22:07 +0900 > Takashi Yano wrote: > > If the script > > > > #!/bin/sh > > mkdir -p chunked > > cd chunked > > /cygdrive/c/Program\ Files/Git/mingw64/bin/git init > > mkdir -p abc/def/ghi/jkl def > > cd abc/def/ghi/jkl > > touch foo > > /cygdrive/c/Program\ Files/Git/mingw64/bin/git add foo > > seq 1 1 | xargs touch > > cd ../../../../def > > seq 1 10 | xargs touch > > cd .. > > time /cygdrive/c/Program\ Files/Git/mingw64/bin/git clean -dfx > > > > is used, the hang here: > > Removing abc/def/ghi/jkl/9878 > > Removing abc/def/ghi/jkl > > is more than 10sec. > > > > It seems that removing def/ takes the time, > > and the output stops before displying > > Removing abc/def/ghi/jkl/9879 > > [...] > > Removing abc/def/ghi/jkl/ > > > > I guess the output is just buffered in somewhere > > which is not flushed. > > The same happens in command prompt which started from 'Git CMD' > icon. In this case, not only cygwin but also msys2 is not used. > Therefore, this is the problem of git executable itself in > Git-for-windows. > > -- > Takashi Yano Thank you very much. - Orgad -- 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: Console output hangs in the middle of a line
Hi, On Sun, Feb 20, 2022 at 3:38 PM Takashi Yano wrote: > > On Sun, 20 Feb 2022 13:43:33 +0200 > Orgad Shaneh wrote: > > mkdir -p chunked > > cd chunked > > git init > > mkdir -p abc/def/ghi/jkl def > > cd abc/def/ghi/jkl > > touch foo > > git add foo > > seq 1 1000 | xargs touch > > cd ../../../../def > > seq 1 1 | xargs touch > > cd .. > > git clean -dfx > > Thanks for the test case. However, I cannot reproduce > your problem. > > $ uname -a > CYGWIN_NT-10.0 Express5800-S70 3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin > $ git --version > git version 2.35.1 > > I have made a shell script such as: > > #!/bin/sh > mkdir -p chunked > cd chunked > git init > mkdir -p abc/def/ghi/jkl def > cd abc/def/ghi/jkl > touch foo > git add foo > seq 1 1000 | xargs touch > cd ../../../../def > seq 1 1 | xargs touch > cd .. > time git clean -dfx > > and resut is as follows. > > Removing abc/def/ghi/jkl/1 > Removing abc/def/ghi/jkl/10 > Removing abc/def/ghi/jkl/100 > Removing abc/def/ghi/jkl/1000 > Removing abc/def/ghi/jkl/101 > Removing abc/def/ghi/jkl/102 > Removing abc/def/ghi/jkl/103 > Removing abc/def/ghi/jkl/104 > Removing abc/def/ghi/jkl/105 > Removing abc/def/ghi/jkl/106 > Removing abc/def/ghi/jkl/107 > Removing abc/def/ghi/jkl/108 > [...] > Removing abc/def/ghi/jkl/995 > Removing abc/def/ghi/jkl/996 > Removing abc/def/ghi/jkl/997 > Removing abc/def/ghi/jkl/998 > Removing abc/def/ghi/jkl/999 > Removing def/ > > real0m3.307s > user0m0.296s > sys 0m2.983s > > How long does the test case hang? > > In my environment, from the line > Removing abc/def/ghi/jkl/1 > to the line > Removing abc/def/ghi/jkl/999 > takes less than 1 second, and the line > Removing def/ > takes the rest of the time. > > > -- > Takashi Yano Turns out I was using Git for Windows and not the cygwin release. With cygwin git it works as expected. I'll report to git-for-windows then. Thanks, - Orgad -- 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: Console output hangs in the middle of a line
Hi and thanks for replying. On Wed, 16 Feb 2022 12:01:07 +0200 Takashi Yano wrote: > On Wed, 16 Feb 2022 18:59:05 +0900 > Takashi Yano wrote: > > On Wed, 16 Feb 2022 11:49:36 +0200 > > Orgad Shaneh wrote: > > > I'm using cygwin runtime 3.3.4-2. CYGWIN env variable is empty. > > > Running in Windows Terminal. > > > > > > When I run git clean -dfx on a Node.JS project, which has huge > > > node_modules directories, that produces a lot of output in high rate, > > > the console seems to freeze for very long in the middle of a line, and > > > continues after a while. If I get it correctly, the writes are done in > > > 4K chunks, freezing for a few seconds after each chunk. > > > > > > The output looks more or less like this: > > > > > > Removing common/auth.js > > > Removing common/auth.js.map > > > ... > > > Removing common/bar.js > > > Removing common/bar.js.map > > > Remo > > > ving common/foo.js (continued on the same line) > > > Removing common/foo.js.map > > > ... > > > etc. > > > > > > No output was lost. > > > > > > Is this a known issue? > > > > Could you please provide reproducible steps for the issue? mkdir -p chunked cd chunked git init mkdir -p abc/def/ghi/jkl def cd abc/def/ghi/jkl touch foo git add foo seq 1 1000 | xargs touch cd ../../../../def seq 1 1 | xargs touch cd .. git clean -dfx Notice that the long operation of cleaning def (that only writes a single line) is not printed immediately. The output here looks like this: Removing abc/def/ghi/jkl/1 Removing abc/def/ghi/jkl/10 Removing abc/def/ghi/jkl/100 Removing abc/def/ghi/jkl/1000 Removing abc/def/ghi/jkl/101 Removing abc/def/ghi/jkl/102 ... Removing abc/def/ghi/jkl/991 Removing ab c/def/ghi/jkl/992 Removing abc/def/ghi/jkl/993 Removing abc/def/ghi/jkl/994 Removing abc/def/ghi/jkl/995 Removing abc/def/ghi/jkl/996 Removing abc/def/ghi/jkl/997 Removing abc/def/ghi/jkl/998 Removing abc/def/ghi/jkl/999 Removing def/ > And, also please check if this issue occurs in command prompt? > (I mean not in Windows Terminal, but cmd.exe.) It does. Please include me when replying. I'm not registered to the mailing list. - Orgad -- 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
Console output hangs in the middle of a line
Hi, I'm using cygwin runtime 3.3.4-2. CYGWIN env variable is empty. Running in Windows Terminal. When I run git clean -dfx on a Node.JS project, which has huge node_modules directories, that produces a lot of output in high rate, the console seems to freeze for very long in the middle of a line, and continues after a while. If I get it correctly, the writes are done in 4K chunks, freezing for a few seconds after each chunk. The output looks more or less like this: Removing common/auth.js Removing common/auth.js.map ... Removing common/bar.js Removing common/bar.js.map Remo ving common/foo.js (continued on the same line) Removing common/foo.js.map ... etc. No output was lost. Is this a known issue? - Orgad -- 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: realpath issue with native[strict] symlinks
On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen wrote: > > I reworked the code handling native symlinks to handle virtual drives > as well. It might even be a tiny bit quicker now. > > The changes have a behavioral change, but I think this is for the > better: Virtual drives are not treated as drives anymore, but as > symlinks. Given they are just pointers to other drives or directories, > tha't much closer to reality. I. e., in case of my above virtual drive > T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is > / only) is this: > > $ ls /cygdrive > $ ls -lG /mnt > total 16 > d---r-x---+ 1 TrustedInstaller 0 Apr 29 21:07 c > drwxr-xr-x 1 corinna 0 Dec 31 1979 e > lrwxrwxrwx 1 corinna 32 May 6 20:43 t -> > /cygdrive/c/cygwin64/home/corinna/tmp > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ > for testing. Thank you very much. Looks good. - Orgad -- 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: realpath issue with native[strict] symlinks
On Thu, May 6, 2021 at 8:44 PM Corinna Vinschen wrote: > > On May 4 22:52, Orgad Shaneh via Cygwin wrote: > > On Tue, Apr 27, 2021 at 8:44 AM Orgad Shaneh wrote: > > > > > > On Apr 19 12:58, Corinna Vinschen via Cygwin wrote: > > > > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote: > > > > > > > I was going to write: > > > > > > > > Nothing we can do about without re-implementing Cygwin's path handling > > > > from scratch. For historical reasons, POSIX paths are evaluated in a > > > > non-POSIXy manner from right to left. If the resulting path is an > > > > existing path, the assumption is that no inner path component is a > > > > symlink. That's true as long as Windows didn't support > > > > symlinks/junctions and Cygwin didn't support them. > > > > > > > > But now I'm writing this: > > > > > > > > Probably I have a workaround for this problem. I added a certain test > > > > to the function checking the outer path component, so the checks for > > > > path validity don't stop at the outer path component, just because > > > > it's a valid Windows path. > > > > > > > > I pushed the patch and uploaded new developer snapshots to > > > > https://cygwin.com/snapshots/ > > > > > > > > Please give them a try. > > > > > > Tried now, and it works for me. Thanks a lot! > > > > > > - Orgad > > > > > > Hi Corinna, > > > > This change breaks access to subst drives. Reported on MSYS2: > > https://github.com/msys2/msys2-runtime/pull/38#issuecomment-832160980 > > > > Can you please have a look? > > Works fine for me: > > $ subst T: C:\\cygwin64\\home\\corinna\\tmp > $ subst > T:\: => C:\cygwin64\home\corinna\tmp > $ ls /cygdrive/t > bar cygwin foo gawk-5.1.0 ocaml openssh-8.5p1 recurse tst > > TAB completion works, too. Right. But if you set / for cygdrive in /etc/fstab it fails: none / cygdrive binary,posix=0,user 0 0 - Orgad -- 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: realpath issue with native[strict] symlinks
On Tue, Apr 27, 2021 at 8:44 AM Orgad Shaneh wrote: > > On Apr 19 12:58, Corinna Vinschen via Cygwin wrote: > > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote: > > > I was going to write: > > > > Nothing we can do about without re-implementing Cygwin's path handling > > from scratch. For historical reasons, POSIX paths are evaluated in a > > non-POSIXy manner from right to left. If the resulting path is an > > existing path, the assumption is that no inner path component is a > > symlink. That's true as long as Windows didn't support > > symlinks/junctions and Cygwin didn't support them. > > > > But now I'm writing this: > > > > Probably I have a workaround for this problem. I added a certain test > > to the function checking the outer path component, so the checks for > > path validity don't stop at the outer path component, just because > > it's a valid Windows path. > > > > I pushed the patch and uploaded new developer snapshots to > > https://cygwin.com/snapshots/ > > > > Please give them a try. > > Tried now, and it works for me. Thanks a lot! > > - Orgad Hi Corinna, This change breaks access to subst drives. Reported on MSYS2: https://github.com/msys2/msys2-runtime/pull/38#issuecomment-832160980 Can you please have a look? Please CC me when you reply. I'm not on the mailing list. Thank you, - Orgad -- 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: realpath issue with native[strict] symlinks
On Apr 19 12:58, Corinna Vinschen via Cygwin wrote: > On Apr 18 10:59, Orgad Shaneh via Cygwin wrote: > I was going to write: > > Nothing we can do about without re-implementing Cygwin's path handling > from scratch. For historical reasons, POSIX paths are evaluated in a > non-POSIXy manner from right to left. If the resulting path is an > existing path, the assumption is that no inner path component is a > symlink. That's true as long as Windows didn't support > symlinks/junctions and Cygwin didn't support them. > > But now I'm writing this: > > Probably I have a workaround for this problem. I added a certain test > to the function checking the outer path component, so the checks for > path validity don't stop at the outer path component, just because > it's a valid Windows path. > > I pushed the patch and uploaded new developer snapshots to > https://cygwin.com/snapshots/ > > Please give them a try. Tried now, and it works for me. Thanks a lot! - Orgad -- 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
realpath issue with native[strict] symlinks
Hi, When winsymlinks:native/nativestrict is used, realpath doesn't resolve the full path correctly, when a symlink to the same directory is used. Example follows. The output is: /home/user/recurse/test/d1 /home/user/recurse/test2/d1 While it should be /home/user/recurse/d1 for both. A few observations: 1. When CYGWIN is not set at all, the link is created as a junction. It works ok in cygwin, but cannot be accessed from cmd (probably because it is a file junction, and not a directory one). On this case, realpath works as expected. 2. If I create a junction using mklink /j test3 ., the issue reproduces, regardless of winsymlinks configuration. #!/bin/sh export CYGWIN=winsymlinks:nativestrict rm -rf recurse mkdir recurse cd recurse mkdir d1 ln -s . test ln -s $PWD test2 cmd ///c 'mklink /j test3 .' (cd test/d1 && realpath .) (cd test2/d1 && realpath .) (cd test3/d1 && realpath .) - Orgad -- 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: A problem with noacl+umask+chmod result
On Sat, Apr 17, 2021 at 8:11 PM Kaz Kylheku (Cygwin) <743-406-3...@kylheku.com> wrote: > > On 2021-04-08 21:34, Orgad Shaneh via Cygwin wrote: > > On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin > > wrote: > >> > >> Greetings, Orgad Shaneh! > >> > >> > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote: > >> > Marco Atzeri replied to the mailing list but did not CC me, so I > >> > didn't receive it: > >> > >> The expectation is that you subscribe to the list of interest. > > > > Why? If I report a bug, I'm interested in this bug, and I don't want > > to receive dozens of emails every day about other issues. > > Hi Orgad, > > The odd thing is that you're able to post at all. > > The Cygwin has an inconsistent configuration: it seems to allow > posts from non-subscribers, yet it removes them from the Cc: line > when remailing their posting. Not sure about this. Some of the replies did include me in CC. If a user appears in "From", any Reply to All should include the sender. > > Every time you report a bug to a project on github/jira/whatever, you > > subscribe to everything in this project? > > Without creating a github account, how do you do anything of that > sort on github? I don't mind registering to gain post access. My concern was about subscribing to the mailing list, and getting many emails that are not related to my issues. - Orgad -- 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: A problem with noacl+umask+chmod result
On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin wrote: > > Greetings, Orgad Shaneh! > > > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote: > >> > >> Hi, > >> > >> If a filesystem is mounted with noacl, calling chmod to add write > >> permissions after umasking this permission doesn't work. Demonstrated > >> with command-line and C++. > >> > >> Did I miss something or is this a real bug? According to umask man, it > >> should only affect newly created files and directories, but I didn't > >> find anything that relates to chmod. > >> > >> Command-line: > >> touch foo > >> ls -l foo > >> # -rw-r--r-- ... foo > >> umask 200 > >> chmod 0 foo > >> ls -l foo > >> # -r--r--r-- ... foo > >> chmod 200 foo > >> ls -l foo > >> # -r--r--r-- ... foo > >> # Expected to have rw > > > Marco Atzeri replied to the mailing list but did not CC me, so I > > didn't receive it: > > The expectation is that you subscribe to the list of interest. Why? If I report a bug, I'm interested in this bug, and I don't want to receive dozens of emails every day about other issues. Every time you report a bug to a project on github/jira/whatever, you subscribe to everything in this project? > >> without ACL you can not expect the POSIX scheme to properly work. > >> see > >> https://cygwin.com/cygwin-ug-net/ntsec.html > >> to understand how Cygwin uses ACL to mimic POSIX permissions > > > Thanks Marco! > > > I'm well aware of that. I don't expect it to work properly. From what > > I know, it can only set/unset user write bit. Read bits are always > > enabled, even on chmod 0. > > > What I do expect is that the write bit will not be affected by umask. > > umask should only affect newly created files, not direct chmod > > commands. > > Yet again: using chmod on noacl filesystem is likely to cause more harm than > good. You may very well end up with an unusable filesystem until you fix > permissions by hands. With noacl, chmod is capable of setting and unsetting the user write bit, and I expect it to do that. I actually found this issue because CMake unit tests failed for me on MSYS which sets noacl. Anyway, I found the curprit. The problem is not with chmod, but with stat. fhandler_base::fstat_helper has this line: /* This fakes the permissions of all files to match the current umask. */ buf->st_mode &= ~(cygheap->umask); So chmod does set the write bit correctly, but stat doesn't report it. I can see why this is needed, so I'll adapt the CMake tests to workaround this. Thank you! - Orgad -- 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: A problem with noacl+umask+chmod result
On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote: > > Hi, > > If a filesystem is mounted with noacl, calling chmod to add write > permissions after umasking this permission doesn't work. Demonstrated > with command-line and C++. > > Did I miss something or is this a real bug? According to umask man, it > should only affect newly created files and directories, but I didn't > find anything that relates to chmod. > > Command-line: > touch foo > ls -l foo > # -rw-r--r-- ... foo > umask 200 > chmod 0 foo > ls -l foo > # -r--r--r-- ... foo > chmod 200 foo > ls -l foo > # -r--r--r-- ... foo > # Expected to have rw Marco Atzeri replied to the mailing list but did not CC me, so I didn't receive it: > without ACL you can not expect the POSIX scheme to properly work. > see > https://cygwin.com/cygwin-ug-net/ntsec.html > to understand how Cygwin uses ACL to mimic POSIX permissions Thanks Marco! I'm well aware of that. I don't expect it to work properly. From what I know, it can only set/unset user write bit. Read bits are always enabled, even on chmod 0. What I do expect is that the write bit will not be affected by umask. umask should only affect newly created files, not direct chmod commands. - Orgad -- 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: Cannot run executable named setlang
On Thu, Apr 8, 2021 at 3:55 PM Takashi Yano wrote: > > On Thu, 8 Apr 2021 15:25:45 +0300 > Orgad Shaneh wrote: > > Hi, > > > > I cannot run an executable if it is named setlang (case insensitive). > > It exits with code 127. > > > > Example: > > cp /bin/ls setlang > > ./setlang -> Error 127 > > > > I've noticed a difference in ldd output. cygwin dlls appear twice. > > > > ldd /bin/ls: > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5) > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > > (0x7ffd9bbb) > > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > > (0x7ffd9b8e) > > cygwin1.dll => /usr/bin/cygwin1.dll (0x18004) > > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff81) > > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff83) > > > > ldd setlang: > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5) > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > > (0x7ffd9bbb) > > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > > (0x7ffd9b8e) > > cygwin1.dll => /usr/bin/cygwin1.dll (0xc1) > > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17) > > cygwin1.dll => /usr/bin/cygwin1.dll (0xc1) > > cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17) > > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60) > > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60) > > > > Any idea what can cause this? > > Isn't this the same issue with: > https://cygwin.com/pipermail/cygwin/2021-January/247508.html > ? Yup, looks like it. Thanks for the reference. We even used the same example :D - Orgad -- 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
Cannot run executable named setlang
Hi, I cannot run an executable if it is named setlang (case insensitive). It exits with code 127. Example: cp /bin/ls setlang ./setlang -> Error 127 I've noticed a difference in ldd output. cygwin dlls appear twice. ldd /bin/ls: ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffd9bbb) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffd9b8e) cygwin1.dll => /usr/bin/cygwin1.dll (0x18004) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff81) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff83) ldd setlang: ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd9be5) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffd9bbb) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffd9b8e) cygwin1.dll => /usr/bin/cygwin1.dll (0xc1) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17) cygwin1.dll => /usr/bin/cygwin1.dll (0xc1) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x17) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x60) Any idea what can cause this? Thanks, - Orgad -- 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
A problem with noacl+umask+chmod result
Hi,
If a filesystem is mounted with noacl, calling chmod to add write
permissions after umasking this permission doesn't work. Demonstrated
with command-line and C++.
Did I miss something or is this a real bug? According to umask man, it
should only affect newly created files and directories, but I didn't
find anything that relates to chmod.
Command-line:
touch foo
ls -l foo
# -rw-r--r-- ... foo
umask 200
chmod 0 foo
ls -l foo
# -r--r--r-- ... foo
chmod 200 foo
ls -l foo
# -r--r--r-- ... foo
# Expected to have rw
C++:
#include
#include
#include
#include
#include
const char fileName[] = "foo";
const int mask = S_IWRITE;
void get()
{
struct stat st;
stat(fileName, &st);
std::cout << (st.st_mode) << std::endl;
}
void set(int mode) {
chmod(fileName, mode);
}
int main() {
std::cout << std::oct;
std::cout << "mask: " << mask << std::endl;
close(open(fileName, O_WRONLY | O_CREAT));
get();
umask(mask);
set(0);
get();
set(mask);
get();
}
Output without noacl:
mask: 200
100644
100444
100644
Output with noacl:
mask: 200
100644
100444
100444
Thanks,
- Orgad
--
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: gawk Regression: CR characters are not stripped on Windows
On Tue, Feb 27, 2018 at 11:48 AM, Andrey Repin wrote: > Greetings, Orgad Shaneh! > >> 1. The gawk info page states that: > >>> Under MS-Windows, > ^^^ >>> 'gawk' (and many other text programs) silently >>> translates end-of-line '\r\n' to '\n' on input and '\n' to '\r\n' on >>> output. > >> and on Feb 8 the following section was added: > >>> Recent versions of Cygwin open all files in binary mode. This means >>> that you should use 'RS = "\r?\n"' in order to be able to handle >>> standard MS-Windows text files with carriage-return plus line-feed line >>> endings. > >> This breaks compatibility between different gawk versions. What were >> the reasons for this change in cygwin, and why was it pushed upstream? > >> 2. Git and other tools automatically convert text files to CRLF on >> Windows. > --^^^ > > Cygwin is not "Windows", it is "sort of Linux". > Besides, this kind silent mangling is dangerous to an unsuspecting user. I see. This is however not true for MSYS2. Then I guess we will just keep this as a patch for MSYS2, which is already merged[1]? [1] https://github.com/Alexpux/MSYS2-packages/commit/c81d882b9838f8245603c7a8d5f8845eeadd6c2a - Orgad -- 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
gawk Regression: CR characters are not stripped on Windows
Hi,
Cross-posting per Eli Zaretskii's request.
CR characters used to be automatically stripped on Windows (MSYS2 and
Cygwin environments). This is broken in 4.2.0.
Minimal example:
echo -en "foo\r\n\r\nbar\r\n" > foo.txt
awk '/^$/ { print "found" }' foo.txt # This worked with 4.1.4 and
doesn't work with 4.2.0
awk '/^\r$/ { print "found" }' foo.txt # This works with 4.2.0 and
doesn't work with 4.1.4
Bisected to commit 5db38f775d9ba239e125d81dff2010a2ddacb48e:
(* gawkmisc.c (cygwin_premain0, cygwin_premain2): Remove.
No longer needed).
Apparently it's still needed...
This issue was reported in https://github.com/git-for-windows/git/issues/1524
Proposed patch is attached.
As Eli said, this change was deliberate. But this has several drawbacks.
1. The gawk info page states that:
> Under MS-Windows, 'gawk' (and many other text programs) silently
> translates end-of-line '\r\n' to '\n' on input and '\n' to '\r\n' on
> output.
and on Feb 8 the following section was added:
> Recent versions of Cygwin open all files in binary mode. This means
> that you should use 'RS = "\r?\n"' in order to be able to handle
> standard MS-Windows text files with carriage-return plus line-feed line
> endings.
This breaks compatibility between different gawk versions. What were
the reasons for this change in cygwin, and why was it pushed upstream?
2. Git and other tools automatically convert text files to CRLF on
Windows. This means that any awk script that runs on both platforms
must use RS = "\r?\n". One example that was broken by this behavior
change is gerrit's commit-msg hook[1], which scans for empty lines by
/^$/ regexp.
Please consider reverting this change. Patch attached.
[1]
https://gerrit.googlesource.com/gerrit/+/376a7bbb64f1b3f13c261f4efa0af0e8538cfe9b/resources/com/google/gerrit/server/tools/root/hooks/commit-msg#101
- Orgad
0001-Revert-default-mode-on-Cygwin-from-binary-back-to-te.patch
Description: Binary data
--
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
Re: FindFirstFile fails for some network directories
On Wed, Aug 19, 2015 at 8:28 AM, Orgad Shaneh wrote: > > On Wed, Aug 19, 2015 at 8:46 AM, Orgad Shaneh wrote: > > Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f > > Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d > > I just found another SMB1 linux server, which does work[1]. > > It first has a "NT Create AndX" request for path \, which succeeds. > Then it issues Trans2 FIND_FIRST2 request for the real path (\a). > > This issue might be related to the Archive bit which is set on aclnas01. > > - Orgad > > [1] https://gist.github.com/orgads/e76a00c2cc0fc8a43d95 Hi, After investigation, I found that the root cause for this problem is set_cygwin_privileges, which sets SE_RESTORE_PRIVILEGE and SE_BACKUP_PRIVILEGE for the process during initialization. Commenting out these 2 lines solves the problem for me. Can you tell why are they needed at all? There is a comment there: Allow to access all files, independent of their ACL settings. What does it mean? - Orgad -- 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
Re: FindFirstFile fails for some network directories
On Wed, Aug 19, 2015 at 8:46 AM, Orgad Shaneh wrote: > Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f > Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d I just found another SMB1 linux server, which does work[1]. It first has a "NT Create AndX" request for path \, which succeeds. Then it issues Trans2 FIND_FIRST2 request for the real path (\a). This issue might be related to the Archive bit which is set on aclnas01. - Orgad [1] https://gist.github.com/orgads/e76a00c2cc0fc8a43d95 -- 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
Re: FindFirstFile fails for some network directories
On Mon, Aug 17, 2015 at 3:03 PM, Orgad Shaneh wrote:
> Hi,
>
> I have 2 network shares with similar contents:
> \\netapp1\CM\CompilationResults
> \\aclnas01\versions\CompilationResults
>
> Trying to list all the files within these directories using Ruby
> succeeds for netapp1, but fails for aclnas01.
>
> The failing ruby command is:
> ruby -e "print Dir.glob('//aclnas01/versions/CompilationResults/*')"
>
> The exact same command succeeds when executed from a normal command
> prompt, or when the directory is on netapp1 (on both shells).
>
> After debugging Ruby, I found out that FindFirstFile returns an
> INVALID_HANDLE when invoked from cygwin environment.
>
> The following application succeeds on command prompt and fails on cygwin:
>
> #include
> #include
>
> int main()
> {
> const TCHAR *aclnas = TEXT("//aclnas01/versions/CompilationResults");
> const TCHAR *netapp = TEXT("//netapp1/CM/CompilationResults");
>
> WIN32_FIND_DATA fd;
> printf("%d\n", FindFirstFile(aclnas, &fd) !=
> INVALID_HANDLE_VALUE); // Fails on cygwin
> printf("%d\n", FindFirstFile(netapp, &fd) !=
> INVALID_HANDLE_VALUE); // Always succeeds
> return 0;
> }
>
> Output on cmd is 1 1, on cygwin it is 0 1.
>
> Process Monitor shows that when executed from cygwin, CreateFile is
> called with Open for Backup flag. I can't say for sure if this causes
> the failure, but that's the only difference I could find between these
> executions.
>
> This bug was previously reported on github/msys2[1], but it wasn't solved.
>
> I only have read access to these servers, but I might have cooperation
> of the sys admin (can't promise though).
>
> Any help will be appreciated.
>
> Thanks,
> - Orgad
>
> [1] https://github.com/Alexpux/MSYS2-packages/issues/242
Hi,
Using Wireshark, I discovered that aclnas01 uses SMB, while netapp1 uses SMB2.
For some reason, when executed from command prompt, a FIND_FIRST2
request is sent and the server replies, while with cygwin a "NT Create
AndX" request is sent and denied.
To minimize the captured packets, I executed the application twice,
and captured only the second execution (to avoid session initiation).
Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f
Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d
Does cygwin implement SMB on its own, or is this difference a
side-effect of the "Backup Intent" flag?
- Orgad
--
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
FindFirstFile fails for some network directories
Hi,
I have 2 network shares with similar contents:
\\netapp1\CM\CompilationResults
\\aclnas01\versions\CompilationResults
Trying to list all the files within these directories using Ruby
succeeds for netapp1, but fails for aclnas01.
The failing ruby command is:
ruby -e "print Dir.glob('//aclnas01/versions/CompilationResults/*')"
The exact same command succeeds when executed from a normal command
prompt, or when the directory is on netapp1 (on both shells).
After debugging Ruby, I found out that FindFirstFile returns an
INVALID_HANDLE when invoked from cygwin environment.
The following application succeeds on command prompt and fails on cygwin:
#include
#include
int main()
{
const TCHAR *aclnas = TEXT("//aclnas01/versions/CompilationResults");
const TCHAR *netapp = TEXT("//netapp1/CM/CompilationResults");
WIN32_FIND_DATA fd;
printf("%d\n", FindFirstFile(aclnas, &fd) !=
INVALID_HANDLE_VALUE); // Fails on cygwin
printf("%d\n", FindFirstFile(netapp, &fd) !=
INVALID_HANDLE_VALUE); // Always succeeds
return 0;
}
Output on cmd is 1 1, on cygwin it is 0 1.
Process Monitor shows that when executed from cygwin, CreateFile is
called with Open for Backup flag. I can't say for sure if this causes
the failure, but that's the only difference I could find between these
executions.
This bug was previously reported on github/msys2[1], but it wasn't solved.
I only have read access to these servers, but I might have cooperation
of the sys admin (can't promise though).
Any help will be appreciated.
Thanks,
- Orgad
[1] https://github.com/Alexpux/MSYS2-packages/issues/242
--
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
