Re: /proc/partitions: add some space to avoid ragged output format

[Thomas Wolff]

Am 03.03.2020 um 00:26 schrieb Brian Inglis:

Hi Thomas,

In this industry, you plan ahead a bit further and longer: you need to go for at
least a three digit increase (below) or more; legacy 8TB HDDs are cheap and
common, 20TB are available, 100TB SSDs are available now (#blocks 9765625 -
11 digits), capacity is expanding *faster* than HDDs:

https://www.tomshardware.com/news/100tb-ssd-nimbus-sata-flash,36687.html

and speeds now exceed 6GB/s and 1M IO/s.

We're also at 64C/128T 6GHz (overclocked) chips with 256MB L3 and L4 caches,
256GB memory, and over the next decade, feature sizes dropping by an order of
magnitude from 14nm to 1.4nm, with corresponding increases, so maintainers
should consider capacity increases when they look at code.

To make this easier next time ;^> I'd define a couple of formats:

#define PROC_PARTITION_HDR  "%5s %5s %12s %s\n\n"
#define PROC_PARTITION_FMT  "%5d %5d %12U %s\n"

or simplify the code further with:

#define PROC_PARTITION_HDR  "%5s %5s %12s %-6s %-s\n\n"
#define PROC_PARTITION_FMT  "%5d %5d %12U %-6s %-s\n"

and sprintf the header into the buffer:

- print ("major minor  #blocks  name   win-mounts\n\n");
+ bufptr += __small_sprintf (bufptr, PROC_PARTITION_HDR,
+   "major", "minor", "#blocks",
+   "name   win-mounts\n\n");

*or*

- print ("major minor  #blocks  name   win-mounts\n\n");
+ bufptr += __small_sprintf (bufptr, PROC_PARTITION_HDR,
+   "major", "minor", "#blocks",
+   "name", "win-mounts\n\n");


Hi Brian,
yes, I thought about factoring out the format as well, but then only 
submitted a quick-and-dirty patch.

If you're suggesting a more solid solution, would you submit your patch?
Thomas



On 2020-03-02 14:39, Thomas Wolff wrote:

---
  winsup/cygwin/fhandler_proc.cc | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc
index 605a8443f..3373f3ef5 100644
--- a/winsup/cygwin/fhandler_proc.cc
+++ b/winsup/cygwin/fhandler_proc.cc
@@ -1491,7 +1491,7 @@ format_proc_partitions (void *, char *)
}
if (!got_one)
{
- print ("major minor  #blocks  name   win-mounts\n\n");
+ print ("major minor#blocks   name   win-mounts\n\n");
  got_one = true;
}
/* Fetch partition info for the entire disk to get its size. */
@@ -1514,7 +1514,7 @@ format_proc_partitions (void *, char *)
  size = 0;
}
device dev (drive_num, 0);
-  bufptr += __small_sprintf (bufptr, "%5d %5d %9U %s\n",
+  bufptr += __small_sprintf (bufptr, "%5d %5d %12U %s\n",
 dev.get_major (), dev.get_minor (),
 size >> 10, dev.name () + 5);
/* Fetch drive layout info to get size of all partitions on the disk. */
@@ -1561,7 +1561,7 @@ format_proc_partitions (void *, char *)
  continue;
device dev (drive_num, part_num);

-   bufptr += __small_sprintf (bufptr, "%5d %5d %9U %s",
+   bufptr += __small_sprintf (bufptr, "%5d %5d %12U %s",
   dev.get_major (), dev.get_minor (),
   size >> 10, dev.name () + 5);
/* Check if the partition is mounted in Windows and, if so,

Re: ASLR revisited

[Lee]

On 3/2/20, John Selbie  wrote:
> And I just discovered that recompiling with this added to the g++ command
> line:
>
>  -Xlinker --dynamicbase
>
> Seems to work. Or at the least, triggers the process to show up in Process
> Explorer as ASLR?
>
> Good idea to continue with this?

I haven't looked at this in ages, but for gcc I use

LDFLAGS="${LDFLAGS} -Wl,--nxcompat"
# https://en.wikipedia.org/wiki/Data_Execution_Prevention
#   Enable DEP with -Wl,--nxcompat

LDFLAGS="${LDFLAGS} -Wl,--dynamicbase,--export-all-symbols"
# https://en.wikipedia.org/wiki/Address_space_layout_randomization
# 
https://stackoverflow.com/questions/24283918/how-can-i-enable-aslr-dep-and-safeseh-on-an-exe-in-codeblocks-using-mingw
#   ASLR with gcc has a problem: -Wl,--dynamicbase doesn't emit the
necessary relocation table.
#   As a workaround, you can pass -Wl,--dynamicbase,--export-all-symbols

Regards,
Lee

--
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

-bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

[Robert McBroom via cygwin]

Details in attached file


Strange problem cropping up.  I chain scripts with command sequences for long 
running numerical calculations executed from the initial mintty terminal. 
Running from a non administrative session.  The form is

---
#!/bin/bash
cd /cygdrive/j/tri60/221-1344c_1.933
mcnp62.sh 221-1344c.mas3.87 221-1344c.baseh.s
mcnp62.sh 221-1344c.mas3.87a 221-1344c.mas3.87.s
sh -v ~/grd.sh &
exit
---

The sequence runs through one or more of the execution groups and then fails 
with

---
@Dell-Studio ~
$ cd /cygdrive/j/tri60/220-1116c_1.993
-bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory
---

I see the directory in emacs and have full access to it.  From the terminal

---
@Dell-Studio ~
$ cd /cygdrive

@Dell-Studio /cygdrive
$ cd j

@Dell-Studio /cygdrive/j
$ cd tri60

@Dell-Studio /cygdrive/j/tri60
$ cd 220-1116c_1.993
-bash: cd: 220-1116c_1.993: No such file or directory
---

From emacs the dired listings are

---
/cygdrive:
  total 84
  dr-xr-xr-x  1   None   0 Feb 24 16:12 .
  drwxr-xr-x+ 1 Qyyy   None   0 Jun  4  2018 ..
  drwxrwx---+ 1 SYSTEM   SYSTEM 0 Feb 24 15:58 c
  drwxrwx---+ 1 SYSTEM   SYSTEM 0 Feb 23 14:42 d
  drwxr-x---+ 1 Qyyy   None   0 Feb  2 23:45 h
  drwsrwsrwx+ 1 Qyyy   None   0 Feb 24 15:48 j
  drwxrwxr-x  1 Unix_User+0  Unix_Group+0   0 Feb 23 14:53 u
  drwxrwxr-x  1 Unix_User+0  Unix_Group+0   0 Mar  7  2019 v
  drwxrwxr-x  1 Unix_User+0  Unix_Group+0   0 Feb  8 15:48 w
  drwxrwxr-x  1 Unix_User+48 Unix_Group+100 0 Apr 22  2021 x
  drwxrwxrwx  1 Unix_User+48 Unix_Group+100 0 Jun  4  2021 z
---

The listing for /cygdrive/j/tri60 is

---
 /cygdrive/j/tri60:
  total used in directory 3569 available 601771488
  drwxrwxrwx+ 1 None0 Feb 24 16:29 .
  drwsrwsrwx+ 1 Qyyy None0 Feb 24 15:48 ..
  drwxrwxr-x+ 1 SYSTEM  0 Jun 25  2012 207-1120c_2.2-kvi
  drwxrwxr-x+ 1 SYSTEM  0 May  9  2012 208-1539c_2.2-kvi
  -rw-rw-rw-+ 1 SYSTEM 39 Nov 24 23:27 212-1513c.len59.619ac.m
  drwxrwsrwx+ 1 SYSTEM  0 Feb 22 22:45 212-1513c_1.642
  -rwxrwxr--+ 1 SYSTEM 181056 Feb 22 11:08 212-1513c_1.642.xlsx
  -rwxrwxr--+ 1 SYSTEM 179379 Apr 10  2012 214-0925_1.642.xlsx
  drwxrwxr-x+ 1 SYSTEM  0 Apr  9  2012 214-0925_1.642-kvi
  drwxrwxrwx+ 1 None0 Jan 31 15:55 214-1010c_1.642
  -rwxrwxr--+ 1 SYSTEM 203825 Feb  8 09:17 214-1010c_1.642.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:33 219-1048c_1.933
  drwxrwxrwx+ 1 None0 Feb 24 15:53 220-1116c_1.933
  -rwxrwxr--+ 1 SYSTEM 160531 Feb 23 15:03 220-1116c_1.933.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:30 221-1344c_1.933
  -rwxrwxr--+ 1 SYSTEM 160451 Feb 22 11:25 221-1344c_1.933.xlsx
  drwxrwxr-x+ 1 SYSTEM  0 May 11  2012 229-1500c_2.63-kvi
  drwxrwxr-x+ 1 SYSTEM  0 May  9  2012 229-1530c_2.63-kvi
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:32 230-c_2.63
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:31 232-1520c_3.11
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:31 234-0911c_3.11
  -rwxrwxr--+ 1 SYSTEM 153152 Mar  8  2012 269-1020c_1.396.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Jan 22 07:57 270-1055c_1.396
  rwxr--+ 1 None   192601 Jan 16 21:09 270-1055c_1.396.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Dec 29 13:48 270-1310_1.396
  -rwxrwxrwx+ 1 None   195249 Jan 24 12:54 270-1310_1.396.xlsx
  drwxrwxr-x+ 1 SYSTEM  0 Jan 11 23:55 271-1405c_1.396
  -rwxrwxrwx+ 1 None   175723 Jan 24 12:55 271-1405c_1.396.xlsx
---

The dired initial elements of the directory of interest

---
/cygdrive/j/tri60/220-1116c_1.933:
  total used in directory 5289808 available 601772000
  drwxrwxrwx+ 1 None0 Feb 24 15:53 .
  drwxrwxrwx+ 1 None0 Feb 23 15:03 ..
  drwxrwsrwx+ 1 None0 Feb 21 01:19 0.65
  -rwxrwxr-x+ 1 None  1943788 Jan 30 06:00 212-1513c.basea.s
  -rwxrwxr-x+ 1 None86340 Feb 23 06:21 220-1116c.bas0.00.log
  -rw-rw-rw-+ 1 None14263 Feb 22 22:18 220-1116c.bas0.00.m
  -rwxrwxr-x+ 1 None  1455095 Feb 23 06:21 220-1116c.bas0.00.o
---

Started Cygwin as an administrator

---
Qyyy@Dell-Studio ~
sh -v ~/grd.sh &

$ #!/bin/bash
cd /cygdrive/j/tri60/220-1116c_1.993
/home//rods.sh: line 2: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file 
or directory
---

Shutdown Cygwin and did a restart of Windows 10 home problems still exist.  
Updated Cygwin.

Problems still exist.

Problems also occur on a new system with Windows 10 pro and fresh Cygwin 
install.  If I make the desired directory the working directory in emacs and 
use the emacs command feature to execute the script, it works. The cd command 
fails but since it is in the proper directory the files are 

Cygwin/X XWinrc menu no longer launches after recent updates

[Roland Roberts]

I only noticed this in the last week or so, and assumed I'd messed up 
something with Windows 10 permission, which is still a possibility. My

first attempt to "fix" this was to reinstall pretty much everything in
Cygwin that was part of X11 or Base. And that seemed to fix 
things...until I rebooted Windows.


There are no errors in the logs, not stackdumps, nothign to indicate 
anything is not working. The X log is below. You'll notice it says


"executing '/bin/mintty', pid 3152"

but that window never opens. If I start a shell directly via my desktop 
shortcut, which has this as it's target


C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -

I can see that there is no PID 3152.

My .XWinrc is this:

 .XWinrc 
menu root {
 "Cygwin Terminal" exec "/bin/mintty -e /bin/bash"
 Emacs exec "/bin/emacs"
 xterm exec "/bin/xterm"
 notepad exec notepad
 SEPARATOR
 FAQEXEC "cygstart 
http://x.cygwin.com/docs/faq/cygwin-x-faq.html;
 "User's Guide" EXEC "cygstart 
http://x.cygwin.com/docs/ug/cygwin-x-ug.html;

 SEPARATOR
 "View logfile" EXEC "xterm -title $XWINLOGFILE -e less +F $XWINLOGFILE"
 SEPARATOR
 "Reload .XWinrc"RELOAD
 SEParATOR
}

RootMenu root


and my .startxwinrc is

 .startxwinrc 
if [ -f $HOME/.Xdefaults ]; then
xrdb -merge $HOME/.Xdefaults &
fi
sleep infinity


I'm lost on what might be causing this. One thing that I *did* change, 
though that was over a month ago, was to add the Cygwin sshd service. On 
the off-chance that that was the issue, I disabled it and rebooted to 
get a clean start. No joy, I still can't launch from the .XWinrc menu. 
The log entry makes it clear that it is seen and is trying.


Oh, and from a mintty shell, if I set DISPLAY=:0.0 when X is running, I 
*can* launch other X apps.


2041 roland> cat XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18363 flamsteed 3.1.4-340.x86_64 2020-02-19 08:49 UTC 
x86_64

OS: Windows 10  [Windows NT 10.0 build 18363] (Win64)
Package: version 1.20.5-3 built 2019-09-06

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -auth
 /home/roland/.serverauth.2909

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 2560 h 1440
winInitializeScreenDefaults - native DPI x 96 y 96
[   734.546] (II) xorg.conf is not supported
[   734.546] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for 
more information

[   734.546] LoadPreferences: Loading /home/roland/.XWinrc
[   734.562] winDetectSupportedEngines - RemoteSession: no
[   734.625] winDetectSupportedEngines - DirectDraw4 installed, allowing 
ShadowDDNL
[   734.625] winDetectSupportedEngines - Returning, supported engines 
0005

[   734.625] winSetEngine - Multi Window or Rootless => ShadowGDI
[   734.625] winScreenInit - Using Windows display depth of 32 bits per 
pixel
[   734.625] winAllocateFBShadowGDI - Creating DIB with width: 3760 
height: 1920 depth: 32

[   734.625] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[   734.625] winInitVisualsShadowGDI - Masks 00ff ff00 00ff 
BPRGB 8 d 24 bpp 32

[   734.625] MIT-SHM extension disabled due to lack of kernel support
[   734.625] XFree86-Bigfont extension local-client optimization 
disabled due to lack of shared memory support in the kernel

[   734.640] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[   735.171] (II) AIGLX: Testing pixelFormatIndex 5
[   735.265] GL_VERSION: 4.6.0 NVIDIA 425.91
[   735.265] GL_VENDOR:  NVIDIA Corporation
[   735.265] GL_RENDERER:Quadro K1000M/PCIe/SSE2
[   735.265] (II) GLX: enabled GLX_SGI_make_current_read
[   735.265] (II) GLX: enabled GLX_SGI_swap_control
[   735.265] (II) GLX: enabled GLX_MESA_swap_control
[   735.265] (II) GLX: enabled GLX_SGIX_pbuffer
[   735.265] (II) GLX: enabled GLX_ARB_multisample
[   735.265] (II) GLX: enabled GLX_SGIS_multisample
[   735.265] (II) GLX: enabled GLX_ARB_fbconfig_float
[   735.265] (II) GLX: enabled GLX_EXT_fbconfig_packed_float
[   735.265] (II) GLX: enabled GLX_ARB_create_context
[   735.265] (II) GLX: enabled GLX_ARB_create_context_profile
[   735.265] (II) GLX: enabled GLX_ARB_create_context_robustness
[   735.265] (II) GLX: enabled GLX_EXT_create_context_es2_profile
[   735.265] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   735.265] (II) 1182 pixel formats reported by 
wglGetPixelFormatAttribivARB

[   735.296] (II) 1146 fbConfigs
[   735.296] (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel 
type, 36 unaccelerated

[   735.296] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[   735.562] winPointerWarpCursor - Discarding first warp: 1880 960
[   735.562] (--) 5 mouse buttons found
[   735.562] (--) Setting autorepeat to delay=500, rate=31
[   735.562] (--) Windows keyboard layout: "0409" (0409) "US", 
type 7

[   735.562] (--) Found matching XKB configuration "English (USA)"
[   

Re: ASLR revisited

[John Selbie]

And I just discovered that recompiling with this added to the g++ command
line:

 -Xlinker --dynamicbase

Seems to work. Or at the least, triggers the process to show up in Process
Explorer as ASLR?

Good idea to continue with this?



On Mon, Mar 2, 2020 at 8:26 PM John Selbie  wrote:

> For my open source project, I publish source code for Unix written in C++.
> And as a convenience, I publish Win32 binaries compiled with Cygwin's g++
> build. I bundled the compiled EXE along with the dependent Cygwin DLLs
> (cygcrypto, cyggcc, cycstdc++, cygwin1, and cygz.dll).
>
> Someone rang me up today and said, "We're about to go live with your
> pre-compiled binaries for Windows, but our compliance testing detected your
> code isn't using ASLR (Address Space Layout Randomization).  Can you fix?"
>
> A quick internet search reveals that Cygwin has a compatibility issue with
> ASRL. Process Explorer from sysinternals.com reveals that the process
> runs without ASLR.
>
> I tried using the Windows 10 Exploit Protection Panel - and specifying an
> exception for this executable to have mandatory ASLR. That results in the
> code no longer running.  Although the alternate option of "Botton-up ASLR"
> did allow the code to run, but Process Explorer still doesn't show it
> running with ASLR.
>
> Is there a workaround for allowing Cygwin code to have ASLR?  I don't need
> the fork() function.
>
> Thanks,
> jrs
>

--
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

ASLR revisited

[John Selbie]

For my open source project, I publish source code for Unix written in C++.
And as a convenience, I publish Win32 binaries compiled with Cygwin's g++
build. I bundled the compiled EXE along with the dependent Cygwin DLLs
(cygcrypto, cyggcc, cycstdc++, cygwin1, and cygz.dll).

Someone rang me up today and said, "We're about to go live with your
pre-compiled binaries for Windows, but our compliance testing detected your
code isn't using ASLR (Address Space Layout Randomization).  Can you fix?"

A quick internet search reveals that Cygwin has a compatibility issue with
ASRL. Process Explorer from sysinternals.com reveals that the process runs
without ASLR.

I tried using the Windows 10 Exploit Protection Panel - and specifying an
exception for this executable to have mandatory ASLR. That results in the
code no longer running.  Although the alternate option of "Botton-up ASLR"
did allow the code to run, but Process Explorer still doesn't show it
running with ASLR.

Is there a workaround for allowing Cygwin code to have ASLR?  I don't need
the fork() function.

Thanks,
jrs

--
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: cat /proc/partitions shows only devices, not partitions

[Hashim Aziz]

Hey Corinna, thanks for your quick reply.

Regarding the elevated shell - I'm unsure of exactly how to run an elevated 
Cygwin shell?

I have attached the requested strace file.

Thanks,
Hashim
 




From: Corinna Vinschen
Sent: Monday, March 02, 2020 4:56 PM
To: Hashim Aziz
Cc: cygwin
Subject: Re: cat /proc/partitions shows only devices, not partitions




On Mar  1 21:16, Hashim Aziz wrote:

> This was an issue that I had previously in September of last year and

> sent the issue to this mailing list ("win-mounts no longer displays

> anything when doing "cat /proc/partitions") but the issue stopped

> occurring before I could get around to diagnosing it. This issue has

> now re-occurred and this time it seems permanent. When I run:

> 

> $ cat /proc/partitions

> major minor  #blocks  name   win-mounts

> 

> 8 0 0 sda

> 8    16 0 sdb

> 8    32 0 sdc

> 8    48 0 sdd

> 8    64 0 sde

> 8    80 0 sdf

> 

> ...I see nothing at all in the win-mounts column. This makes it

> impossible for me to see which Windows drive letter maps to which

> /dev/sdX entry. On closer inspection, this seems to be because I'm not

> actually seeing any partitions of my drives, even though there are

> many - for example, I see /dev/sda but no /dev/sda1 or /dev/sda2, and

> because it's the partitions that are mounted, it's this that seems to

> result in me seeing nothing in the win-mounts column. I'm running

> Cygwin on Windows 7 (yes I'm aware it's EOL).



Fortunately I just started Windows 7 for another thread here, so I

gave it a try myself:



  $ uname -a

  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin

  $ id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated

  non-elevated

  $ cat /proc/partitions

  major minor  #blocks  name   win-mounts



  8 0  54525952 sda

  8 1    102400 sda1

  8 2  54420480 sda2   C:\



So, https://cygwin.com/acronyms/#WJFFM



This appears to be a local phenomenon only, either some permission

problem, or some BLODA, a life virus scanner or something.



Two questions come to mind:



- Does it work in an elevated shell?



- If you run this under strace, does it show anything unusual?

  We could take a look if you call



    strace -o cat.trace cat /proc/partitions



  and send the cat.trace file here (assuming it still doesn't work).





Corinna



-- 

Corinna Vinschen

Cygwin Maintainer



cat.trace
Description: cat.trace

--
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: cat /proc/partitions shows only devices, not partitions

[Hashim Aziz]

Hey Corinna, thanks for your quick reply.

Regarding the elevated shell - I'm unsure of exactly how to run an elevated 
Cygwin shell?

I have attached the requested strace file.

Thanks,
Hashim
 




From: Corinna Vinschen
Sent: Monday, March 02, 2020 4:56 PM
To: Hashim Aziz
Cc: cygwin
Subject: Re: cat /proc/partitions shows only devices, not partitions




On Mar  1 21:16, Hashim Aziz wrote:

> This was an issue that I had previously in September of last year and

> sent the issue to this mailing list ("win-mounts no longer displays

> anything when doing "cat /proc/partitions") but the issue stopped

> occurring before I could get around to diagnosing it. This issue has

> now re-occurred and this time it seems permanent. When I run:

> 

> $ cat /proc/partitions

> major minor  #blocks  name   win-mounts

> 

> 8 0 0 sda

> 8    16 0 sdb

> 8    32 0 sdc

> 8    48 0 sdd

> 8    64 0 sde

> 8    80 0 sdf

> 

> ...I see nothing at all in the win-mounts column. This makes it

> impossible for me to see which Windows drive letter maps to which

> /dev/sdX entry. On closer inspection, this seems to be because I'm not

> actually seeing any partitions of my drives, even though there are

> many - for example, I see /dev/sda but no /dev/sda1 or /dev/sda2, and

> because it's the partitions that are mounted, it's this that seems to

> result in me seeing nothing in the win-mounts column. I'm running

> Cygwin on Windows 7 (yes I'm aware it's EOL).



Fortunately I just started Windows 7 for another thread here, so I

gave it a try myself:



  $ uname -a

  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin

  $ id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated

  non-elevated

  $ cat /proc/partitions

  major minor  #blocks  name   win-mounts



  8 0  54525952 sda

  8 1    102400 sda1

  8 2  54420480 sda2   C:\



So, https://cygwin.com/acronyms/#WJFFM



This appears to be a local phenomenon only, either some permission

problem, or some BLODA, a life virus scanner or something.



Two questions come to mind:



- Does it work in an elevated shell?



- If you run this under strace, does it show anything unusual?

  We could take a look if you call



    strace -o cat.trace cat /proc/partitions



  and send the cat.trace file here (assuming it still doesn't work).





Corinna



-- 

Corinna Vinschen

Cygwin Maintainer



cat.trace
Description: cat.trace

--
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: [PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.

[Takashi Yano]

Hi Hans,

Thanks for the patch.

On Tue, 3 Mar 2020 00:07:25 +0100
Hans-Bernhard Bröker wrote:
> +  inline void sendOut(HANDLE , DWORD *wn) { WriteConsoleA 
> (handle, buf, ixput, wn, 0); };

The second argument DWORD *wn of sendOut() is not used
outside sendOut(), so it can be covered up like:

inline void sendOut (HANDLE )
{
  DWORD wn;
  WriteConsoleA (handle, buf, ixput, , 0);
}

-- 
Takashi Yano 

Re: /proc/partitions: add some space to avoid ragged output format

[Brian Inglis]

Hi Thomas,

In this industry, you plan ahead a bit further and longer: you need to go for at
least a three digit increase (below) or more; legacy 8TB HDDs are cheap and
common, 20TB are available, 100TB SSDs are available now (#blocks 9765625 -
11 digits), capacity is expanding *faster* than HDDs:

https://www.tomshardware.com/news/100tb-ssd-nimbus-sata-flash,36687.html

and speeds now exceed 6GB/s and 1M IO/s.

We're also at 64C/128T 6GHz (overclocked) chips with 256MB L3 and L4 caches,
256GB memory, and over the next decade, feature sizes dropping by an order of
magnitude from 14nm to 1.4nm, with corresponding increases, so maintainers
should consider capacity increases when they look at code.

To make this easier next time ;^> I'd define a couple of formats:

#define PROC_PARTITION_HDR  "%5s %5s %12s %s\n\n"
#define PROC_PARTITION_FMT  "%5d %5d %12U %s\n"

or simplify the code further with:

#define PROC_PARTITION_HDR  "%5s %5s %12s %-6s %-s\n\n"
#define PROC_PARTITION_FMT  "%5d %5d %12U %-6s %-s\n"

and sprintf the header into the buffer:

- print ("major minor  #blocks  name   win-mounts\n\n");
+ bufptr += __small_sprintf (bufptr, PROC_PARTITION_HDR,
+   "major", "minor", "#blocks",
+   "name   win-mounts\n\n");

*or*

- print ("major minor  #blocks  name   win-mounts\n\n");
+ bufptr += __small_sprintf (bufptr, PROC_PARTITION_HDR,
+   "major", "minor", "#blocks",
+   "name", "win-mounts\n\n");


On 2020-03-02 14:39, Thomas Wolff wrote:

---
 winsup/cygwin/fhandler_proc.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc
index 605a8443f..3373f3ef5 100644
--- a/winsup/cygwin/fhandler_proc.cc
+++ b/winsup/cygwin/fhandler_proc.cc
@@ -1491,7 +1491,7 @@ format_proc_partitions (void *, char *)
}
   if (!got_one)
{
- print ("major minor  #blocks  name   win-mounts\n\n");
+ print ("major minor#blocks   name   win-mounts\n\n");
  got_one = true;
}
   /* Fetch partition info for the entire disk to get its size. */
@@ -1514,7 +1514,7 @@ format_proc_partitions (void *, char *)
  size = 0;
}
   device dev (drive_num, 0);
-  bufptr += __small_sprintf (bufptr, "%5d %5d %9U %s\n",
+  bufptr += __small_sprintf (bufptr, "%5d %5d %12U %s\n",
 dev.get_major (), dev.get_minor (),
 size >> 10, dev.name () + 5);
   /* Fetch drive layout info to get size of all partitions on the disk. */
@@ -1561,7 +1561,7 @@ format_proc_partitions (void *, char *)
  continue;
device dev (drive_num, part_num);

-   bufptr += __small_sprintf (bufptr, "%5d %5d %9U %s",
+   bufptr += __small_sprintf (bufptr, "%5d %5d %12U %s",
   dev.get_major (), dev.get_minor (),
   size >> 10, dev.name () + 5);
/* Check if the partition is mounted in Windows and, if so,

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

[PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.

[Hans-Bernhard Bröker]

Replace direct access to a pair of co-dependent variables
by calls to methods of a class that encapsulates their relation.

Also replace C #define by C++ class constant.
---
 winsup/cygwin/fhandler_console.cc | 135 --
 1 file changed, 70 insertions(+), 65 deletions(-)

diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc

index c5f269168..af2fb11a4 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -59,17 +59,22 @@ static struct fhandler_base::rabuf_t con_ra;
  /* Write pending buffer for ESC sequence handling
in xterm compatible mode */
-#define WPBUF_LEN 256
-static unsigned char wpbuf[WPBUF_LEN];
-static int wpixput;
 static unsigned char last_char;
 -static inline void
-wpbuf_put (unsigned char x)
+// simple helper class to accumulate output in a buffer
+// and send that to the console on request:
+static class WritePendingBuf
 {
-  if (wpixput < WPBUF_LEN)
-wpbuf[wpixput++] = x;
-}
+private:
+  static const size_t WPBUF_LEN = 256u;
+  unsigned char buf[WPBUF_LEN];
+  size_t ixput;
+
+public:
+  inline void put(unsigned char x) { if (ixput < WPBUF_LEN) { 
buf[ixput++] = x; } };

+  inline void empty() { ixput = 0u; };
+  inline void sendOut(HANDLE , DWORD *wn) { WriteConsoleA 
(handle, buf, ixput, wn, 0); };

+} wpbuf;
  static void
 beep ()
@@ -2030,10 +2035,10 @@ fhandler_console::char_command (char c)
  break;
 #endif
case 'b': /* REP */
- wpbuf_put (c);
+ wpbuf.put (c);
  if (wincap.has_con_esc_rep ())
/* Just send the sequence */
-   WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+   wpbuf.sendOut( get_output_handle (), );
  else if (last_char && last_char != '\n')
for (int i = 0; i < con.args[0]; i++)
  WriteConsoleA (get_output_handle (), _char, 1, , 0);
@@ -2041,9 +2046,9 @@ fhandler_console::char_command (char c)
case 'r': /* DECSTBM */
  con.scroll_region.Top = con.args[0] ? con.args[0] - 1 : 0;
  con.scroll_region.Bottom = con.args[1] ? con.args[1] - 1 : -1;
- wpbuf_put (c);
+ wpbuf.put (c);
  /* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
  break;
case 'L': /* IL */
  if (wincap.has_con_broken_il_dl ())
@@ -2067,8 +2072,8 @@ fhandler_console::char_command (char c)
   y + 1 - con.b.srWindow.Top,
   srBottom + 1 - con.b.srWindow.Top);
  WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
- wpbuf_put ('T');
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.put ('T');
+ wpbuf.sendOut( get_output_handle (), );
  __small_sprintf (buf, "\033[%d;%dr",
   srTop + 1 - con.b.srWindow.Top,
   srBottom + 1 - con.b.srWindow.Top);
@@ -2079,9 +2084,9 @@ fhandler_console::char_command (char c)
}
  else
{
- wpbuf_put (c);
+ wpbuf.put (c);
  /* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
}
  break;
case 'M': /* DL */
@@ -2095,8 +2100,8 @@ fhandler_console::char_command (char c)
   y + 1 - con.b.srWindow.Top,
   srBottom + 1 - con.b.srWindow.Top);
  WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
- wpbuf_put ('S');
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.put ('S');
+ wpbuf.sendOut( get_output_handle (), );
  __small_sprintf (buf, "\033[%d;%dr",
   srTop + 1 - con.b.srWindow.Top,
   srBottom + 1 - con.b.srWindow.Top);
@@ -2107,13 +2112,13 @@ fhandler_console::char_command (char c)
}
  else
{
- wpbuf_put (c);
+ wpbuf.put (c);
  /* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
}
  break;
case 'J': /* ED */
- wpbuf_put (c);
+ wpbuf.put (c);
  if (con.args[0] == 3 && wincap.has_con_broken_csi3j ())
{ /* Workaround for broken CSI3J in Win10 1809 */
  CONSOLE_SCREEN_BUFFER_INFO sbi;
@@ -2131,7 +2136,7 @@ fhandler_console::char_command (char c)
}
  else
/* Just send the sequence */
-   WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+   wpbuf.sendOut( get_output_handle (), );
  break;

[PATCH 0/1] Handle wpbuf in a more C++ style

[Hans-Bernhard Bröker]

Replace a relatively C-styled co-dependent pair of variables, a #define, 
and an inline function by a helper class containing their relation, 
because that is more in the C++ style.


Hans-Bernhard Broeker (1):
  Collect handling of wpixput and wpbuf into a helper class.

 winsup/cygwin/fhandler_console.cc | 135 --
 1 file changed, 70 insertions(+), 65 deletions(-)

--
2.21.0

Copyright License waiver

[Hans-Bernhard Bröker]

To whom it may concern,

I hereby grant anyone the rights to any use code I send here under the 
standard 2-clause BSD license statement as found, among other places, in 
winsup/cygwin/CONTRIBUTORS.


Hans-Bernhard Bröker

/proc/partitions: add some space to avoid ragged output format

[Thomas Wolff]

From 2e33b27e7d4683062f21a3082ec634a440ff9387 Mon Sep 17 00:00:00 2001
From: Thomas Wolff 
Date: Mon, 2 Mar 2020 22:36:56 +0100
Subject: [PATCH] avoid ragged output of /proc/partitions

---
 winsup/cygwin/fhandler_proc.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc
index 605a8443f..3373f3ef5 100644
--- a/winsup/cygwin/fhandler_proc.cc
+++ b/winsup/cygwin/fhandler_proc.cc
@@ -1491,7 +1491,7 @@ format_proc_partitions (void *, char *)
}
   if (!got_one)
{
- print ("major minor  #blocks  name   win-mounts\n\n");
+ print ("major minor   #blocks   name   win-mounts\n\n");
  got_one = true;
}
   /* Fetch partition info for the entire disk to get its size. */
@@ -1514,7 +1514,7 @@ format_proc_partitions (void *, char *)
  size = 0;
}
   device dev (drive_num, 0);
-  bufptr += __small_sprintf (bufptr, "%5d %5d %9U %s\n",
+  bufptr += __small_sprintf (bufptr, "%5d %5d %11U %s\n",
 dev.get_major (), dev.get_minor (),
 size >> 10, dev.name () + 5);
   /* Fetch drive layout info to get size of all partitions on the disk. */
@@ -1561,7 +1561,7 @@ format_proc_partitions (void *, char *)
  continue;
device dev (drive_num, part_num);
 
-   bufptr += __small_sprintf (bufptr, "%5d %5d %9U %s",
+   bufptr += __small_sprintf (bufptr, "%5d %5d %11U %s",
   dev.get_major (), dev.get_minor (),
   size >> 10, dev.name () + 5);
/* Check if the partition is mounted in Windows and, if so,
-- 
2.21.0

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

[Brian Inglis]

On 2020-03-02 13:17, Robert McBroom via cygwin wrote:
> #!/bin/bash
>cd /cygdrive/j/tri60/221-1344c_1.642
>/home/xxx/grd.sh: line 2: cd: 
> /cygdrive/j/tri60/221-
> 1344c_1.642: No such file or directory
>   mcnp62.sh 221-1344c.mas3.71 
> 221-1344c.mas3.83a.s

Any time I see stair stepped output, I suspect Windows code reading Unix text
without CRs:

#!/bin/bash
   cd /cygdrive/j/tri60/221-1344c_1.642
   /home/xxx/grd.sh: line 2: cd:
/cygdrive/j/tri60/221-
1344c_1.642: No such file or directory
  mcnp62.sh 221-1344c.mas3.71
221-1344c.mas3.83a.s

Please check your script line terminators by running file on them, where your
PATH points, and if you are running a non-Cygwin Windows executable by running
type PROG, which -a PROG, cygcheck on the full explicit executable path, and
that cygwin1.dll is listed in the output.

You may also see the opposite effect, running Cygwin on \r\n terminated scripts,
where cd dir\r fails.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: [PATCH v2 1/4] Cygwin: console: Add workaround for broken IL/DL in xterm mode.

[Jon Turney]

On 02/03/2020 19:54, Corinna Vinschen wrote:

On Mar  2 18:03, Corinna Vinschen wrote:

On Mar  1 15:38, Takashi Yano wrote:

Hi Hans,

[...]


I pushed wpbuf_put as a simple inline function as a stop-gap
measure so Cygwin builds on gcc 9.2.0.


\o/

https://ci.appveyor.com/project/cygwin/cygwin/builds/31190427

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

[Marco Atzeri]

Am 02.03.2020 um 21:17 schrieb Robert McBroom via cygwin:

Details in attached file



better in line next time.

Are you sure that the disk J is mounted in a Administrator account ?

Regards
Marco


--
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

-bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

[Robert McBroom via cygwin]

Details in attached file

Strange problem cropping up.  I chain scripts with command sequences for long 
running numerical calculations executed from the initial mintty terminal. 
Running from a non administrative session.  The form is

---
#!/bin/bash
cd /cygdrive/j/tri60/221-1344c_1.933
mcnp62.sh 221-1344c.mas3.87 221-1344c.baseh.s
mcnp62.sh 221-1344c.mas3.87a 221-1344c.mas3.87.s
sh -v ~/grd.sh &
exit
---

The sequence runs through one or more of the execution groups and then fails 
with

---
@Dell-Studio ~
$ cd /cygdrive/j/tri60/220-1116c_1.993
-bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory
---

I see the directory in emacs and have full access to it.  From the terminal

---
@Dell-Studio ~
$ cd /cygdrive

@Dell-Studio /cygdrive
$ cd j

@Dell-Studio /cygdrive/j
$ cd tri60

@Dell-Studio /cygdrive/j/tri60
$ cd 220-1116c_1.993
-bash: cd: 220-1116c_1.993: No such file or directory
---

From emacs the dired listings are

---
/cygdrive:
  total 84
  dr-xr-xr-x  1   None   0 Feb 24 16:12 .
  drwxr-xr-x+ 1 Qyyy   None   0 Jun  4  2018 ..
  drwxrwx---+ 1 SYSTEM   SYSTEM 0 Feb 24 15:58 c
  drwxrwx---+ 1 SYSTEM   SYSTEM 0 Feb 23 14:42 d
  drwxr-x---+ 1 Qyyy   None   0 Feb  2 23:45 h
  drwsrwsrwx+ 1 Qyyy   None   0 Feb 24 15:48 j
  drwxrwxr-x  1 Unix_User+0  Unix_Group+0   0 Feb 23 14:53 u
  drwxrwxr-x  1 Unix_User+0  Unix_Group+0   0 Mar  7  2019 v
  drwxrwxr-x  1 Unix_User+0  Unix_Group+0   0 Feb  8 15:48 w
  drwxrwxr-x  1 Unix_User+48 Unix_Group+100 0 Apr 22  2021 x
  drwxrwxrwx  1 Unix_User+48 Unix_Group+100 0 Jun  4  2021 z
---

The listing for /cygdrive/j/tri60 is

---
 /cygdrive/j/tri60:
  total used in directory 3569 available 601771488
  drwxrwxrwx+ 1 None0 Feb 24 16:29 .
  drwsrwsrwx+ 1 Qyyy None0 Feb 24 15:48 ..
  drwxrwxr-x+ 1 SYSTEM  0 Jun 25  2012 207-1120c_2.2-kvi
  drwxrwxr-x+ 1 SYSTEM  0 May  9  2012 208-1539c_2.2-kvi
  -rw-rw-rw-+ 1 SYSTEM 39 Nov 24 23:27 212-1513c.len59.619ac.m
  drwxrwsrwx+ 1 SYSTEM  0 Feb 22 22:45 212-1513c_1.642
  -rwxrwxr--+ 1 SYSTEM 181056 Feb 22 11:08 212-1513c_1.642.xlsx
  -rwxrwxr--+ 1 SYSTEM 179379 Apr 10  2012 214-0925_1.642.xlsx
  drwxrwxr-x+ 1 SYSTEM  0 Apr  9  2012 214-0925_1.642-kvi
  drwxrwxrwx+ 1 None0 Jan 31 15:55 214-1010c_1.642
  -rwxrwxr--+ 1 SYSTEM 203825 Feb  8 09:17 214-1010c_1.642.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:33 219-1048c_1.933
  drwxrwxrwx+ 1 None0 Feb 24 15:53 220-1116c_1.933
  -rwxrwxr--+ 1 SYSTEM 160531 Feb 23 15:03 220-1116c_1.933.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:30 221-1344c_1.933
  -rwxrwxr--+ 1 SYSTEM 160451 Feb 22 11:25 221-1344c_1.933.xlsx
  drwxrwxr-x+ 1 SYSTEM  0 May 11  2012 229-1500c_2.63-kvi
  drwxrwxr-x+ 1 SYSTEM  0 May  9  2012 229-1530c_2.63-kvi
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:32 230-c_2.63
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:31 232-1520c_3.11
  drwxrwsrwx+ 1 SYSTEM  0 Feb  7 15:31 234-0911c_3.11
  -rwxrwxr--+ 1 SYSTEM 153152 Mar  8  2012 269-1020c_1.396.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Jan 22 07:57 270-1055c_1.396
  rwxr--+ 1 None   192601 Jan 16 21:09 270-1055c_1.396.xlsx
  drwxrwsrwx+ 1 SYSTEM  0 Dec 29 13:48 270-1310_1.396
  -rwxrwxrwx+ 1 None   195249 Jan 24 12:54 270-1310_1.396.xlsx
  drwxrwxr-x+ 1 SYSTEM  0 Jan 11 23:55 271-1405c_1.396
  -rwxrwxrwx+ 1 None   175723 Jan 24 12:55 271-1405c_1.396.xlsx
---

The dired initial elements of the directory of interest

---
/cygdrive/j/tri60/220-1116c_1.933:
  total used in directory 5289808 available 601772000
  drwxrwxrwx+ 1 None0 Feb 24 15:53 .
  drwxrwxrwx+ 1 None0 Feb 23 15:03 ..
  drwxrwsrwx+ 1 None0 Feb 21 01:19 0.65
  -rwxrwxr-x+ 1 None  1943788 Jan 30 06:00 212-1513c.basea.s
  -rwxrwxr-x+ 1 None86340 Feb 23 06:21 220-1116c.bas0.00.log
  -rw-rw-rw-+ 1 None14263 Feb 22 22:18 220-1116c.bas0.00.m
  -rwxrwxr-x+ 1 None  1455095 Feb 23 06:21 220-1116c.bas0.00.o
---

Started Cygwin as an administrator

---
Qyyy@Dell-Studio ~
sh -v ~/grd.sh &

$ #!/bin/bash
cd /cygdrive/j/tri60/220-1116c_1.993
/home//rods.sh: line 2: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file 
or directory
---

Shutdown Cygwin and did a restart of Windows 10 home problems still exist.  
Updated Cygwin.

Problems still exist.

Problems also occur on a new system with Windows 10 pro and fresh Cygwin 
install.  If I make the desired directory the working directory in emacs and 
use the emacs command feature to execute the script, it works. The cd command 
fails but since it is in the proper directory the files are 

Re: [PATCH v2 1/4] Cygwin: console: Add workaround for broken IL/DL in xterm mode.

[Corinna Vinschen]

On Mar  2 18:03, Corinna Vinschen wrote:
> On Mar  1 15:38, Takashi Yano wrote:
> > Hi Hans,
> > 
> > On Sat, 29 Feb 2020 19:10:02 +0100
> > Hans-Bernhard Bröker wrote:
> > > One more important note: the current implementation has a potential 
> > > buffer overrun issue, because it writes first, and only then checks 
> > > whether that may have overrun the buffer.  And the check itself is off 
> > > by one, too:
> > > 
> > > >wpbuf[wpixput++] = x; \
> > > >if (wpixput > WPBUF_LEN) \
> > > > wpixput--; \
> > > 
> > > That's why my latest code snippet does it differently:
> > > 
> > >  >  if (ixput < WPBUF_LEN)
> > >  >{
> > >  >  buf[ixput++] = x;
> > >  >}
> > 
> > Indeed. You are right. Thanks for pointing out that.
> > Another similar problem exists in console code of escape
> > sequence handling, so I will submit a patch for that.
> > 
> > As for wpbuf, please continue to fix.
> 
> Yeah, a patch in `git format-patch' format would be most welcome.
> 
> For a first-time contribution (and then never again) we also need
> a 2-clause BSD license waiver per https://cygwin.com/contrib.html

I pushed wpbuf_put as a simple inline function as a stop-gap
measure so Cygwin builds on gcc 9.2.0.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

[newlib-cygwin] Cygwin: console: convert wpbuf_put to inline function

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ecf27dd2e0ed1dff4dc919a7c805e951913d953f

commit ecf27dd2e0ed1dff4dc919a7c805e951913d953f
Author: Corinna Vinschen 
Date:   Mon Mar 2 20:30:09 2020 +0100

Cygwin: console: convert wpbuf_put to inline function

fix potential buffer overrun while at it

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fhandler_console.cc | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc
index dffee24..c5f2691 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -63,10 +63,13 @@ static struct fhandler_base::rabuf_t con_ra;
 static unsigned char wpbuf[WPBUF_LEN];
 static int wpixput;
 static unsigned char last_char;
-#define wpbuf_put(x) \
-  wpbuf[wpixput++] = x; \
-  if (wpixput > WPBUF_LEN) \
-wpixput--;
+
+static inline void
+wpbuf_put (unsigned char x)
+{
+  if (wpixput < WPBUF_LEN)
+wpbuf[wpixput++] = x;
+}
 
 static void
 beep ()

Re: [PATCH 0/4] Cygwin: console: Some fixes for console in xterm mode.

[Corinna Vinschen]

On Mar  2 10:12, Takashi Yano wrote:
> Takashi Yano (4):
>   Cygwin: console: Revise the code to fix tab position.
>   Cygwin: console: Fix setting/unsetting xterm mode for input.
>   Cygwin: console: Prevent buffer overrun.
>   Cygwin: console: Add a workaround for "ESC 7" and "ESC 8".
> 
>  winsup/cygwin/fhandler.h  |  1 +
>  winsup/cygwin/fhandler_console.cc | 91 ++-
>  2 files changed, 55 insertions(+), 37 deletions(-)
> 
> -- 
> 2.21.0

Pushed.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

[newlib-cygwin] Cygwin: console: Prevent buffer overrun.

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=750cd6e5b2bb4ab74de7d2f9e0afb6dd0c005cf1

commit 750cd6e5b2bb4ab74de7d2f9e0afb6dd0c005cf1
Author: Takashi Yano 
Date:   Mon Mar 2 10:12:56 2020 +0900

Cygwin: console: Prevent buffer overrun.

- This patch prevent potential buffer overrun in the code handling
  escape sequences.

Diff:
---
 winsup/cygwin/fhandler_console.cc | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc
index 9c5b801..8b46877 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -3094,7 +3094,8 @@ fhandler_console::write (const void *vsrc, size_t len)
case gotarg1:
  if (isdigit (*src))
{
- con.args[con.nargs] = con.args[con.nargs] * 10 + *src - '0';
+ if (con.nargs < MAXARGS)
+   con.args[con.nargs] = con.args[con.nargs] * 10 + *src - '0';
  wpbuf_put (*src);
  src++;
}
@@ -3102,9 +3103,8 @@ fhandler_console::write (const void *vsrc, size_t len)
{
  wpbuf_put (*src);
  src++;
- con.nargs++;
- if (con.nargs > MAXARGS)
-   con.nargs--;
+ if (con.nargs < MAXARGS)
+   con.nargs++;
}
  else if (*src == ' ')
{
@@ -3117,9 +3117,8 @@ fhandler_console::write (const void *vsrc, size_t len)
con.state = gotcommand;
  break;
case gotcommand:
- con.nargs ++;
- if (con.nargs > MAXARGS)
-   con.nargs--;
+ if (con.nargs < MAXARGS)
+   con.nargs++;
  char_command (*src++);
  con.state = normal;
  wpixput = 0;
@@ -3183,9 +3182,8 @@ fhandler_console::write (const void *vsrc, size_t len)
{
  con.state = gotarg1;
  wpbuf_put (*src);
- con.nargs++;
- if (con.nargs > MAXARGS)
-   con.nargs--;
+ if (con.nargs < MAXARGS)
+   con.nargs++;
  src++;
}
  else if (isalpha (*src))

[newlib-cygwin] Cygwin: console: Add a workaround for "ESC 7" and "ESC 8".

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=b4bc238311ca66ce34de5bec2f8219e881cedfd0

commit b4bc238311ca66ce34de5bec2f8219e881cedfd0
Author: Takashi Yano 
Date:   Mon Mar 2 10:12:57 2020 +0900

Cygwin: console: Add a workaround for "ESC 7" and "ESC 8".

- In xterm compatible mode, "ESC 7" and "ESC 8" do not work properly
  in the senario:
   1) Execute /bin/ls /bin to fill screen.
   2) Sned CSI?1049h to alternate screen.
   3) Reduce window size.
   4) Send CSI?1049l to resume screen.
   5) Send "ESC 7" and "ESC 8".
  After sending "ESC 8", the cursor goes to incorrect position. This
  patch adds a workaround for this issue.

Diff:
---
 winsup/cygwin/fhandler.h  |  1 +
 winsup/cygwin/fhandler_console.cc | 53 +--
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index adaf192..463bb83 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -1869,6 +1869,7 @@ class dev_console
   bool alternate_charset_active;
   bool metabit;
   char backspace_keycode;
+  bool screen_alternated; /* For xterm compatible mode only */
 
   char my_title_buf [TITLESIZE + 1];
 
diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc
index 8b46877..dffee24 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -207,6 +207,8 @@ fhandler_console::setup ()
   con.dwLastCursorPosition.Y = -1;
   con.dwLastMousePosition.X = -1;
   con.dwLastMousePosition.Y = -1;
+  con.savex = con.savey = -1;
+  con.screen_alternated = false;
   con.dwLastButtonState = 0;   /* none pressed */
   con.last_button_code = 3;/* released */
   con.underline_color = FOREGROUND_GREEN | FOREGROUND_BLUE;
@@ -2130,6 +2132,10 @@ fhandler_console::char_command (char c)
  break;
case 'h': /* DECSET */
case 'l': /* DECRST */
+ if (c == 'h')
+   con.screen_alternated = true;
+ else
+   con.screen_alternated = false;
  wpbuf_put (c);
  /* Just send the sequence */
  WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
@@ -2989,6 +2995,36 @@ fhandler_console::write (const void *vsrc, size_t len)
  con.saw_space = false;
  con.saw_exclamation_mark = false;
}
+ else if (*src == '8') /* DECRC Restore cursor position */
+   {
+ if (con.screen_alternated)
+   {
+ /* For xterm mode only */
+ DWORD n;
+ /* Just send the sequence */
+ wpbuf_put (*src);
+ WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+   }
+ else if (con.savex >= 0 && con.savey >= 0)
+   cursor_set (false, con.savex, con.savey);
+ con.state = normal;
+ wpixput = 0;
+   }
+ else if (*src == '7') /* DECSC Save cursor position */
+   {
+ if (con.screen_alternated)
+   {
+ /* For xterm mode only */
+ DWORD n;
+ /* Just send the sequence */
+ wpbuf_put (*src);
+ WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+   }
+ else
+   cursor_get (, );
+ con.state = normal;
+ wpixput = 0;
+   }
  else if (wincap.has_con_24bit_colors () && !con_is_legacy
   && wincap.has_con_broken_il_dl () && *src == 'M')
{ /* Reverse Index (scroll down) */
@@ -3019,12 +3055,15 @@ fhandler_console::write (const void *vsrc, size_t len)
  wpixput = 0;
}
  else if (wincap.has_con_24bit_colors () && !con_is_legacy)
-   { /* Only CSI is handled in xterm compatible mode. */
+   {
  if (*src == 'c') /* RIS Full reset */
{
  con.scroll_region.Top = 0;
  con.scroll_region.Bottom = -1;
}
+ /* ESC sequences below (e.g. OSC, etc) are left to xterm
+emulation in xterm compatible mode, therefore, are not
+handled and just sent them. */
  wpbuf_put (*src);
  /* Just send the sequence */
  DWORD n;
@@ -3067,18 +3106,6 @@ fhandler_console::write (const void *vsrc, size_t len)
  con.state = normal;
  wpixput = 0;
}
- else if (*src == '8') /* DECRC Restore cursor position */
-   {
- cursor_set (false, con.savex, con.savey);
- con.state = normal;
- wpixput = 0;
-   }
- else if (*src == '7') /* DECSC Save cursor position */
-   {
- cursor_get (, );
- 

[newlib-cygwin] Cygwin: console: Fix setting/unsetting xterm mode for input.

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=10d8c2782d79dd5744027e93831dd77aeab452fc

commit 10d8c2782d79dd5744027e93831dd77aeab452fc
Author: Takashi Yano 
Date:   Mon Mar 2 10:12:55 2020 +0900

Cygwin: console: Fix setting/unsetting xterm mode for input.

- This patch fixes the issue that xterm compatible mode for input
  is not correctly set/unset in some situation such as:
   1) cat is stopped by ctrl-c.
   2) The window size is changed in less.
  In case 1), request_xterm_mode_input(true) is called in read(),
  however, cat is stopped without request_xterm_mode_input(false).
  In case 2), less uses longjmp in signal handler, therefore,
  corresponding request_xterm_mode_input(false) is not called if
  the SIGWINCH signal is sent within read(). With this patch,
  InterlockedExchange() is used instead of InterlockedIncrement/
  Decrement().

Diff:
---
 winsup/cygwin/fhandler_console.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc
index 7c97a78..9c5b801 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -267,7 +267,7 @@ fhandler_console::request_xterm_mode_input (bool req)
 return;
   if (req)
 {
-  if (InterlockedIncrement (_mode_input) == 1)
+  if (InterlockedExchange (_mode_input, 1) == 0)
{
  DWORD dwMode;
  GetConsoleMode (get_handle (), );
@@ -277,7 +277,7 @@ fhandler_console::request_xterm_mode_input (bool req)
 }
   else
 {
-  if (InterlockedDecrement (_mode_input) == 0)
+  if (InterlockedExchange (_mode_input, 0) == 1)
{
  DWORD dwMode;
  GetConsoleMode (get_handle (), );
@@ -1171,6 +1171,7 @@ fhandler_console::close ()
   if ((NT_SUCCESS (status) && obi.HandleCount == 1)
  || myself->pid == con.owner)
request_xterm_mode_output (false);
+  request_xterm_mode_input (false);
 }
 
   release_output_mutex ();

[newlib-cygwin] Cygwin: console: Revise the code to fix tab position.

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=7f5051d76662838103666492a33505e0801c1ee7

commit 7f5051d76662838103666492a33505e0801c1ee7
Author: Takashi Yano 
Date:   Mon Mar 2 10:12:54 2020 +0900

Cygwin: console: Revise the code to fix tab position.

- This patch fixes the issue that the cursor position is broken if
  window size is changed while executing vim, less etc.

Diff:
---
 winsup/cygwin/fhandler_console.cc | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/winsup/cygwin/fhandler_console.cc 
b/winsup/cygwin/fhandler_console.cc
index 64e12b8..7c97a78 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -417,19 +417,10 @@ fhandler_console::set_cursor_maybe ()
 void
 fhandler_console::fix_tab_position (void)
 {
-  char buf[2048] = {0,};
-  /* Save cursor position */
-  __small_sprintf (buf+strlen (buf), "\0337");
-  /* Clear all horizontal tabs */
-  __small_sprintf (buf+strlen (buf), "\033[3g");
-  /* Set horizontal tabs */
-  for (int col=8; col

Re: Cygwin-X shortcut no longer works after recent updates

[Ronald Blaschke]

On 2/28/20 8:21 AM, Brian Inglis wrote:
> Hi folks,
> 
> After the recent upgrades to cygwin 3.1.4, perl, etc. I have found that the
> Cygwin-X Startup, Start Menu, and Task Bar shortcuts no longer work, although 
> I
> can start Cygwin-X by running startxwin from a mintty window.
> 
>>From the shortcut, the shell is invoked to run startxwin normally, two copies 
>>of
> xinit fork, and Xwin runs and displays the start tray Xserver icon, but my
> mintty terminal and the xwin-xdg-menu clients don't start.

I think I am seeing the same problem. Here are a few observations.

1) The issue happens often, but not always, when starting with the
Windows shortcut.  Currently, I am retrying a few times until the
startup works.  I have been unable to reproduce the issue starting
startxwin from a mintty window.

2) XWin always seems to start fine.

3) If the issue comes up, I am always seeing the following hanging
process tree.

3969 cons0S  0:00  \_ xinit ...
 3970 cons0S  0:00  \_ /usr/bin/XWin ...
 3974 ?Ss 0:00  \_ /usr/bin/sh 

In Windows, this looks like so.

C:\cygwin64\bin\xinit.exe
\_ C:\cygwin64\bin\xinit.exe
  \_ C:\cygwin64\bin\sh.exe
C:\cygwin64\bin\XWin.exe

Currently, I am killing the defunct sh, which seems to properly clean up
everything, and try again.

Ron

--
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

Setup: How to automate source download for packages already installed?

[Bill Stewart]

I would like to reinstall a set of packages and automatically install the
source for only those packages.

The packages are currently installed, and I am using a Setup command line
like this:

 -I -P "package1,package2,package3"

The description in --help for -I states "Automatically install source for
every package installed".

It would seem that, in this case, since the named packages are already
installed and up-to-date, the -I option does nothing.

Is my analysis correct?

If so, what is the way to automate source download for a set of packages
that are already installed?

Bill

--
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

[ANNOUNCEMENT] Re-Released: isl-0.22.1-2

[Achim Gratz]

The current version of isl is re-released for Cygwin.  This release is
now compiled by gcc-9.2.0 and the "isl" package, which has been empty
for some time, has been obsoleted.


ISL is a library for manipulating sets and relations of integer points
bounded by linear constraints. Supported operations on sets include
intersection, union, set difference, emptiness check, convex hull,
(integer) affine hull, integer projection, and computing the
lexicographic minimum using parametric integer programming. It also
includes an ILP solver based on generalized basis reduction and
operations geared towards polyhedral compilation such as dependence
analysis, scheduling, and AST generation.


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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-Released: isl-0.22.1-2

[Achim Gratz]

The current version of isl is re-released for Cygwin.  This release is
now compiled by gcc-9.2.0 and the "isl" package, which has been empty
for some time, has been obsoleted.


ISL is a library for manipulating sets and relations of integer points
bounded by linear constraints. Supported operations on sets include
intersection, union, set difference, emptiness check, convex hull,
(integer) affine hull, integer projection, and computing the
lexicographic minimum using parametric integer programming. It also
includes an ILP solver based on generalized basis reduction and
operations geared towards polyhedral compilation such as dependence
analysis, scheduling, and AST generation.


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

[ANNOUNCEMENT] Re-Released: gmp-6.2.0-2

[Achim Gratz]

The current version of gmp has been re-released for Cygwin.  This
release is now compiled by gcc-9.2.0 and the "gmp" package, which has
been empty for some time, has been obsoleted.


GNU Multiple Precision Arithmetic Library
=

GMP is a free library for arbitrary precision arithmetic, operating on
signed integers, rational numbers, and floating point numbers. There is
no practical limit to the precision except the ones implied by the
available memory in the machine GMP runs on. GMP has a rich set of
functions, and the functions have a regular interface.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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-Released: gmp-6.2.0-2

[Achim Gratz]

The current version of gmp has been re-released for Cygwin.  This
release is now compiled by gcc-9.2.0 and the "gmp" package, which has
been empty for some time, has been obsoleted.


GNU Multiple Precision Arithmetic Library
=

GMP is a free library for arbitrary precision arithmetic, operating on
signed integers, rational numbers, and floating point numbers. There is
no practical limit to the precision except the ones implied by the
available memory in the machine GMP runs on. GMP has a rich set of
functions, and the functions have a regular interface.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: flexdll error: cannot relocate RELOC_REL32

[Achim Gratz]

Brian Inglis writes:
> Try what's documented in /usr/share/doc/Cygwin/_autorebase.README for DLLs 
> under
> non-standard system paths:

…which by some extension  means you shouldn't add system paths.

> create a file /var/lib/rebase/dynpath.d/ocaml containing your .so directory 
> path
> /usr/lib/ocaml/stublibs/:

Don't.  The OCaml stublibs must not be rebased.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: flexdll error: cannot relocate RELOC_REL32

[Achim Gratz]

Cao Qinxiang writes:
> I use Cygwin-64 on windows and get a fork problem when I try to manually
> install menhir package.
>
> 
>  0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by
> 'dllunix.so' (0x40) is already occupied
> /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends
>   0 [main] ocamlrun 1616 child_info_fork::abort: address space needed
> by 'dllunix.so' (0x40) is already occupied
> /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed:
> Resource temporarily unavailable
> 
>
> I follow online suggestion to run "/usr/bin/rebaseall -v" using ash.exe.
> However, I get another program after that:

The dynamic objects for OCaml must not be rebased, they simply stop
working if you try.  They are specifically exempted from getting picked
up by autorebase for this very reason.  If you rebased them manually or
somehow managed to overwrite them with other versions (opam sometimes
does this and it seems you are trying some sort of OCaml build whenjh
this happens, which may have done this), you should re-installl all
OCaml packages of your installation.

> 
> Fatal error: cannot load shared library dllunix
> Reason: flexdll error: cannot relocate RELOC_REL32, target is too far:
> 0xfffc02088b5f  0x2088b5f
> 
>
> I searched solutions for this new problem. Most solutions are to manually
> rebase dllunix to a lower number like 0x0644. However, I cannot
> do that. Here is what I get in Cygwin:
>
> 
> $ rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so
> rebase: Invalid Baseaddress 0x0644, must be > 0x2
> 

All of these solutions are wrong, IMHO (even on 32bit).

> So, what should I do to this problem?
>
> Also, if I did not use "/usr/bin/rebaseall -v" using ash.exe, but follow
> FAQ's suggestion (run "rebase-trigger fullrebase" in Cygwin), then I cannot
> solve the fork problem and still get
> 
>  0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by
> 'dllunix.so' (0x40) is already occupied
> /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends
>   0 [main] ocamlrun 1616 child_info_fork::abort: address space needed
> by 'dllunix.so' (0x40) is already occupied
> /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork" failed:
> Resource temporarily unavailable
> 

This is a very low load address and that indicates there is either BLODA
involved or you've managed to have two different versions of dllunix.so
loaded into memroy at the same time.  Again, it seems you are trying to
do a build with OCaml, you must ensure it doesn't create libraries you
already have installed from Cygwin packages and certainly to not
overwrite them.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: [PATCH v2 1/4] Cygwin: console: Add workaround for broken IL/DL in xterm mode.

[Corinna Vinschen]

On Mar  1 15:38, Takashi Yano wrote:
> Hi Hans,
> 
> On Sat, 29 Feb 2020 19:10:02 +0100
> Hans-Bernhard Bröker wrote:
> > One more important note: the current implementation has a potential 
> > buffer overrun issue, because it writes first, and only then checks 
> > whether that may have overrun the buffer.  And the check itself is off 
> > by one, too:
> > 
> > >wpbuf[wpixput++] = x; \
> > >if (wpixput > WPBUF_LEN) \
> > > wpixput--; \
> > 
> > That's why my latest code snippet does it differently:
> > 
> >  >  if (ixput < WPBUF_LEN)
> >  >{
> >  >  buf[ixput++] = x;
> >  >}
> 
> Indeed. You are right. Thanks for pointing out that.
> Another similar problem exists in console code of escape
> sequence handling, so I will submit a patch for that.
> 
> As for wpbuf, please continue to fix.

Yeah, a patch in `git format-patch' format would be most welcome.

For a first-time contribution (and then never again) we also need
a 2-clause BSD license waiver per https://cygwin.com/contrib.html


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Cygwin-X shortcut no longer works after recent updates

[Henry S. Thompson]

Jon Turney writes:

> On 28/02/2020 07:21, Brian Inglis wrote:
>> Hi folks,
>>
>> After the recent upgrades to cygwin 3.1.4, perl, etc. I have found that the
>> Cygwin-X Startup, Start Menu, and Task Bar shortcuts no longer work, 
>> although I
>> can start Cygwin-X by running startxwin from a mintty window.

Ditto.

> Two copies of xinit suggests to me that it is getting stuck somewhere
> in the cygwin fork/exec of /etc/X11/xinit/startxwinrc (which in turn
> starts ~/.startxwinrc if it exists) to start clients.

A bit more detail, from pstree -Aap:

 |-sh,2027 /usr/bin/startxwin
 |   `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow -auth 
...
 |   |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027
 |   `-sh,2065

>> My .startxwinrc is a copy of /etc/X11/xinit/startxwinrc with addition of the
>> minnty terminal startup in bg before leaving xwin-xdg-menu running in fg.

Mine was just a two-liner, changing it to none or
/etc/X11/xint/startxwinrc has no effect.

Aha.  A similar problem occurs with xemacs when launched from a shortcut
with command

  H:\C64\bin\run.exe -p /home/ht/bin:/usr/local/bin:/usr/bin 
/usr/local/bin/xemacs-21.5-b34.exe

The common denominator is clearer run.exe -- does that give anyone a
useful clue?

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


--
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: cat /proc/partitions shows only devices, not partitions

[Corinna Vinschen]

On Mar  1 21:16, Hashim Aziz wrote:
> This was an issue that I had previously in September of last year and
> sent the issue to this mailing list ("win-mounts no longer displays
> anything when doing "cat /proc/partitions") but the issue stopped
> occurring before I could get around to diagnosing it. This issue has
> now re-occurred and this time it seems permanent. When I run:
> 
> $ cat /proc/partitions
> major minor  #blocks  name   win-mounts
> 
> 8 0 0 sda
> 816 0 sdb
> 832 0 sdc
> 848 0 sdd
> 864 0 sde
> 880 0 sdf
> 
> ...I see nothing at all in the win-mounts column. This makes it
> impossible for me to see which Windows drive letter maps to which
> /dev/sdX entry. On closer inspection, this seems to be because I'm not
> actually seeing any partitions of my drives, even though there are
> many - for example, I see /dev/sda but no /dev/sda1 or /dev/sda2, and
> because it's the partitions that are mounted, it's this that seems to
> result in me seeing nothing in the win-mounts column. I'm running
> Cygwin on Windows 7 (yes I'm aware it's EOL).

Fortunately I just started Windows 7 for another thread here, so I
gave it a try myself:

  $ uname -a
  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
  $ id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
  non-elevated
  $ cat /proc/partitions
  major minor  #blocks  name   win-mounts

  8 0  54525952 sda
  8 1102400 sda1
  8 2  54420480 sda2   C:\

So, https://cygwin.com/acronyms/#WJFFM

This appears to be a local phenomenon only, either some permission
problem, or some BLODA, a life virus scanner or something.

Two questions come to mind:

- Does it work in an elevated shell?

- If you run this under strace, does it show anything unusual?
  We could take a look if you call

strace -o cat.trace cat /proc/partitions

  and send the cat.trace file here (assuming it still doesn't work).


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Change in logical link behaviour

[Corinna Vinschen]

On Feb 29 14:10, Rainer Emrich wrote:
> I try to reliably determine if native Windows symlink are working for a
> current cygwin environment in a shell script.
> 
> Therefor I used a powershell snipped:
> 
> mkdir asdfgh
> ln -s asdfgh/ asdfgh-1
> powershell "& {Get-Item -Path asdfgh-1 | Select-Object}"
> 
> On cygwin 3.0.7 the output is as follows:
> 
> 
> Directory: D:\cygwin\home\rainer\temp
> 
> 
> ModeLastWriteTime Length Name
> - -- 
> dl   29.02.2020 13:58asdfgh-1
> 
> On cygwin 3.1.4 I get:
> 
> 
> Directory: D:\cygwin\home\rainer\temp
> 
> 
> ModeLastWriteTime Length Name
> - -- 
> d29.02.2020 13:58asdfgh-1
> 
> So now there is no indication that this is a link. Is this new behaviour
> intended or a bug?
> 
> I did not try on Windows 10, I'm still on windows 7.
> 
> Rainer
> 

I can't reproduce this behaviour.  Keep in mind that, by default, you
*have to* run in an elevated shell to be able to create native NTFS
symlinks, *and* you *have to* set the environment variable CYGWIN(*) to
contain "winsymlinks:native" or "winsymlinks:nativestrict".  The latter
is nice for testing, it refuses to fall back silently to the default
Cygwin-only symlinks but fails instead if it can't create a native
NTFS symlink.

So, on Windows 7 in an elevated shell:

  # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
  elevated
  # uname -a
  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
  # mkdir qwe
  # cd qwe
  # export CYGWIN="winsymlinks:nativestrict"
  # touch foo
  # ln -s foo bar
  # cmd /c dir /a
   Volume in drive C has no label.
   Volume Serial Number is A8E0-A24E

   Directory of C:\cygwin64\home\corinna\qwe

  2020-03-02  17:31  .
  2020-03-02  17:31  ..
  2020-03-02  17:31  bar [foo]
  2020-03-02  17:31 0 foo
 2 File(s)  0 bytes
 2 Dir(s)   7.907.352.576 bytes free

In a non-elevated shell:

  $ id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
  non-elevated
  $ uname -r
  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
  $ cd qwe
  $ export CYGWIN="winsymlinks:nativestrict"
  $ rm bar
  $ ln -s foo bar
  ln: failed to create symbolic link 'bar': Operation not permitted
  $ export CYGWIN="winsymlinks:native"  # !!!
  $ ln -s foo bar
  $ cmd /c dir /a
   Volume in drive C has no label.
   Volume Serial Number is A8E0-A24E

   Directory of C:\cygwin64\home\corinna\qwe

  2020-03-02  17:31  .
  2020-03-02  17:31  ..
  2020-03-02  17:3820 bar
  2020-03-02  17:31 0 foo
 2 File(s) 20 bytes
 2 Dir(s)   7.907.352.576 bytes free

The symlink created last is a Cygwin-only symlink (special file
with SYSTEM attribute), not a native symlink.


Corinna

(*) https://cygwin.com/cygwin-ug-net/using-cygwinenv.html
(*) https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks


-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: flexdll error: cannot relocate RELOC_REL32

[Brian Inglis]

On 2020-03-02 05:57, Cao Qinxiang wrote:
> On Mon, Mar 2, 2020 at 3:58 PM Brian Inglis wrote:
>> On 2020-03-01 11:35, Cao Qinxiang wrote:
>>> I use Cygwin-64 on windows and get a fork problem when I try to manually 
>>> install menhir package.>> 0 [main] ocamlrun 1615 child_info_fork::abort: 
>>> address space needed by 'dllunix.so' (0x40) is already occupied
>>> /usr/bin/ocamldep.opt -modules menhir.ml  > 
>>> menhir.ml.depends
>>> 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed by
>>> 'dllunix.so' (0x40) is already occupied
>>> /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork"
>>> failed: Resource temporarily unavailable
>>> I follow online suggestion to run "/usr/bin/rebaseall -v" using ash.exe.
>>> However, I get another program after that:
>>> Fatal error: cannot load shared library dllunix
>>> Reason: flexdll error: cannot relocate RELOC_REL32, target is too far:
>>> 0xfffc02088b5f  0x2088b5f
>>> I searched solutions for this new problem. Most solutions are to manually 
>>> rebase dllunix to a lower number like 0x0644. However, I cannot do
>>> that. Here is what I get in Cygwin:
>>> $ rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so
>>> rebase: Invalid Baseaddress 0x0644, must be > 0x2
>>> So, what should I do to this problem?
>>> Also, if I did not use "/usr/bin/rebaseall -v" using ash.exe, but follow 
>>> FAQ's suggestion (run "rebase-trigger fullrebase" in Cygwin), then I
>>> cannot solve the fork problem and still get
>>> 0 [main] ocamlrun 1615 child_info_fork::abort: address space needed by 
>>> 'dllunix.so' (0x40) is already occupied
>>> /usr/bin/ocamldep.opt -modules menhir.ml  > 
>>> menhir.ml.depends
>>> 0 [main] ocamlrun 1616 child_info_fork::abort: address space needed by
>>> 'dllunix.so' (0x40) is already occupied
>>> /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork"
>>> failed: Resource temporarily unavailable
>> Run rebase-trigger full then shut down *ALL* Cygwin processes: check Task 
>> Manager Details tab Image path name column for process paths under Cygwin
>> root and kill.
>> If rebase-trigger full fails, create /var/cache/rebase/fullrebase.
>> Then download and run Cygwin setup and let all the postinstall scripts
>> complete.

> Thank you for you reply.
> But it does not solve my problem. When I run "rebase-trigger full", I get the
> following message:
> Note: _autorebase will do a full rebase the next time setup is run.
> If I check /var/cache/rebase/fullrebase at this time, it contains the follow
> information:
> # _autorebase will do a rebuild of the rebase database if this file
> # exists and then rename it to fullrebase.done
> Then I closed Cygwin and checked Task Manager Details (found no exe in
> cygwin folder). Then I run Cygwin setup. But after I rerun Cygwin again, I
> get the same error message about dllunix.so. BTW, in
> /var/cache/rebase/rebase_all, I found nothing related to dllunix.so. Is a the
> reason? I attached my /var/cache/rebase/ folder to this email and hope it can
> help detect the problem.
Try what's documented in /usr/share/doc/Cygwin/_autorebase.README for DLLs under
non-standard system paths:

create a file /var/lib/rebase/dynpath.d/ocaml containing your .so directory path
/usr/lib/ocaml/stublibs/:

$ echo /usr/lib/ocaml/stublibs/ > /var/lib/rebase/dynpath.d/ocaml

then rebase-trigger full, shutdown all Cygwin processes, rerun setup, and your
Cygwin setup should be properly rebased including your added DLLs/SOs.

If you were testing as a user, you should add your build paths to
/var/lib/rebase/user.d/$USER e.g.

$ echo $HOME/src/build/lib/ocam/stublibs/ > /var/lib/rebase/user.d/$USER

and do the above to pick up the added paths and include them in the Cygwin
rebase database.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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

How to rebase correctly? ml archive link

[Brian Inglis]

How to rebase correctly?
https://cygwin.com/ml/cygwin/2015-10/msg00159.html

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: Incorrect behavior in TIOCINQ ioctl

[Corinna Vinschen]

On Feb 29 11:37, Åke Rehnman wrote:
> 
> On 2020-02-28 20:23, Corinna Vinschen wrote:
> 
> > - Is it a safe bet that ClearCommError returns valid values in
> >st.cbInQue even if one of the error conditions occur?  Maybe the
> >right thing to do is to return 0 in certain error cases...?
> 
> The win32 api  documentation does not mention anything about not returning
> proper device status as long as the function succeeds...
> 
> Anyhow in my pursuit for the truth I whipped up a small test program and
> strace:d it (with some extra debug printout in fhandler_serial::ioctl)
> 
>  127 2403456 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=7
>   216 3406481 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=E
>    90 4409676 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=15
>   141 5413027 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=1C
>   129 6416204 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=23
>   121 7419254 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=2A
>   203 8423829 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=31
>    89 9427183 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=38
>   131 10431271 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=3F
>   118 11435254 [main] python2.7 1662 fhandler_serial::ioctl: 0 = ioctl(541B,
> 0xBCB0) ev=C st.cbInQue=46
> 
> > 
> > - Did you actually try if this fixes your problem?  It's pretty
> >simple to build the Cygwin DLL
> >https://cygwin.com/faq.html#faq.programming.building-cygwin
> 
> I patched it yesterday and it solved the problem...
> 
> /Ake

I pushed a patch.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

[newlib-cygwin] Cygwin: ioctl: TIOCINQ: always return number of chars in the inbound queue

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=1b7fcf22bea529fba920310dcd2db144bb24ccc6

commit 1b7fcf22bea529fba920310dcd2db144bb24ccc6
Author: Corinna Vinschen 
Date:   Mon Mar 2 17:02:51 2020 +0100

Cygwin: ioctl: TIOCINQ: always return number of chars in the inbound queue

So far ioctl(TIOCINQ) could end up returning -1 with errno set to EINVAL
if a non-zero device error mask has been returned by ClearCommError.
This doesn't reflect Linux behaviour, which always returns the number of
chars in the inbound queue, independent of any I/O error condition.
EINVAL was a pretty weird error code to use in this scenario, too.

Fix this by dropping all checking for device errors in the TIOCINQ
case.  Just return the number of chars in the inbound queue.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fhandler_serial.cc | 9 +
 winsup/cygwin/release/3.1.5  | 3 +++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/winsup/cygwin/fhandler_serial.cc b/winsup/cygwin/fhandler_serial.cc
index 615b251..69e5768 100644
--- a/winsup/cygwin/fhandler_serial.cc
+++ b/winsup/cygwin/fhandler_serial.cc
@@ -519,14 +519,7 @@ fhandler_serial::ioctl (unsigned int cmd, void *buf)
  }
break;
  case TIOCINQ:
-   if (ev & CE_FRAME || ev & CE_IOE || ev & CE_OVERRUN || ev & CE_RXOVER
-  || ev & CE_RXPARITY)
-{
-  set_errno (EINVAL);  /* FIXME: Use correct errno */
-  res = -1;
-}
-   else
-ipbuf = st.cbInQue;
+   ipbuf = st.cbInQue;
break;
  case TIOCGWINSZ:
((struct winsize *) buf)->ws_row = 0;
diff --git a/winsup/cygwin/release/3.1.5 b/winsup/cygwin/release/3.1.5
index e34fdb8..e567ecb 100644
--- a/winsup/cygwin/release/3.1.5
+++ b/winsup/cygwin/release/3.1.5
@@ -9,3 +9,6 @@ Bug Fixes:
 - Fix a segfault when starting, e.g., mintty from a bash in a console
   running xterm emulation.
   Addresses: https://cygwin.com/ml/cygwin/2020-02/msg00197.html
+
+- Fix TIOCINQ to always return number of inbound chars if available.
+  Addresses: https://cygwin.com/ml/cygwin/2020-02/msg00258.html

Re: flexdll error: cannot relocate RELOC_REL32

[Cao Qinxiang]

Dear Brian,

Thank you for you reply.

But it does not solve my problem. When I run "rebase-trigger full", I get
the following message:
-
Note: _autorebase will do a full rebase the next time setup is run.
-

If I check /var/cache/rebase/fullrebase at this time, it contains the
follow information:
-
# _autorebase will do a rebuild of the rebase database if this file
# exists and then rename it to fullrebase.done
-

Then I closed Cygwin and checked Task Manager Details (found no exe in
cygwin folder). Then I run Cygwin setup. But after I rerun Cygwin again, I
get the same error message about dllunix.so. BTW, in
/var/cache/rebase/rebase_all, I found nothing related to dllunix.so. Is a
the reason? I put my /var/cache/rebase/ folder in this git repo "
https://github.com/QinxiangCao/CygwinDebug; and hope it can help detect
the problem.

Thank you very much!

Best regards,
Qinxiang Cao
Shanghai Jiao Tong University, John Hopcroft Center
Room 1110-2, SJTUSE Building
800 Dongchuan Road, Shanghai, China, 200240



On Mon, Mar 2, 2020 at 3:58 PM Brian Inglis  wrote:

> On 2020-03-01 11:35, Cao Qinxiang wrote:
> > Dear Cygwin development team and Cygwin experts,
> >
> > I use Cygwin-64 on windows and get a fork problem when I try to manually
> > install menhir package.
> >
> > 
> >  0 [main] ocamlrun 1615 child_info_fork::abort: address space needed
> by
> > 'dllunix.so' (0x40) is already occupied
> > /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends
> >   0 [main] ocamlrun 1616 child_info_fork::abort: address space needed
> > by 'dllunix.so' (0x40) is already occupied
> > /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork"
> failed:
> > Resource temporarily unavailable
> > 
> >
> > I follow online suggestion to run "/usr/bin/rebaseall -v" using ash.exe.
> > However, I get another program after that:
> >
> >
> > 
> > Fatal error: cannot load shared library dllunix
> > Reason: flexdll error: cannot relocate RELOC_REL32, target is too far:
> > 0xfffc02088b5f  0x2088b5f
> > 
> >
> > I searched solutions for this new problem. Most solutions are to manually
> > rebase dllunix to a lower number like 0x0644. However, I cannot
> > do that. Here is what I get in Cygwin:
> >
> > 
> > $ rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so
> > rebase: Invalid Baseaddress 0x0644, must be > 0x2
> > 
> >
> > So, what should I do to this problem?
> >
> > Also, if I did not use "/usr/bin/rebaseall -v" using ash.exe, but follow
> > FAQ's suggestion (run "rebase-trigger fullrebase" in Cygwin), then I
> cannot
> > solve the fork problem and still get
> > 
> >  0 [main] ocamlrun 1615 child_info_fork::abort: address space needed
> by
> > 'dllunix.so' (0x40) is already occupied
> > /usr/bin/ocamldep.opt -modules menhir.ml > menhir.ml.depends
> >   0 [main] ocamlrun 1616 child_info_fork::abort: address space needed
> > by 'dllunix.so' (0x40) is already occupied
> > /cygdrive/g/Cygwin/menhir-20190924/src/_stage1/myocamlbuild: "fork"
> failed:
> > Resource temporarily unavailable
> > 
>
> Run rebase-trigger full then shut down *ALL* Cygwin processes: check Task
> Manager Details tab Image path name column for process paths under Cygwin
> root
> and kill.
> If rebase-trigger full fails, create /var/cache/rebase/fullrebase.
> Then download and run Cygwin setup and let all the postinstall scripts
> complete.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
>

--
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