Re: New installation of Cygwin64: xinit.sh exit code 3

[Frank-Ulrich Sommer via Cygwin]

I seem to have almost excatly the same problem except that I could not solve it 
by removing the Cygwin-X folder. In this case during the reinstallation of the 
xinit package the folder is recreated again and then the original error message 
(xinit.sh exit code 3) reappears. The directory again has strange permissions  
when checked with Windows Explorer and I am not allowed the enter it or see its 
contents before resetting the security settings.

When doing an "ls -l" (within Cygwin) in the "Start Menu" folder the group and 
owner for the Cygwin-X directory seem to be reversed compared to other folders manually created 
from Windows Explorer (i.e. the user name appears in the group column and vice versa) but I'm not 
sure if this is important:

d---rwxr-x+ 1 myusername Administratoren    0 May 10 02:27  Cygwin-X

For all other folders the group is displayed before the username.

I had to fix the security settings for the Cygwin-X folder and then manually execute the last two 
"mkshortcut" commands from "/etc/postinstall/xinit.sh" (replacing $CYGWINFORALL with 
"-A" and ${wow64} with an empty string).

Should this be the only problem and should my "fix" be correct? And is there 
anything I can do to help find the cause for this problem?



On 23.10.2023 17:41, Brian Inglis via Cygwin wrote:

On 2023-10-23 06:05, Fergus Daly via Cygwin wrote:

<< Detail >>


When I used Explorer to visit C:\ProgramData\Microsoft\Windows\Start 
Menu\Cygwin-X I was told:
"You don't currently have permission to access this folder"
and clicking on Continue to get access I was told:
"You have been denied permission to access this folder"
There was then offered an option to edit Permissions which I didn't feel like 
pursuing.
(I am the Administrator on my own standalone Windows machine. The denial of 
access to Cygwin-X feels odd.
PS I also have Cygwin32 installed and running. I _am_ permitted access to the 
equivalent folder Cygwin-X (32-bit).)



Please try running the following command/s, under Cygwin 32 and 64, and posting
the outputs:



$ for p in "`cygpath -A -P -U`"{,/Cygwin-X}; do for c in 'lsattr -d' 'ls -dl'
getfacl; do $c "$p"; echo; done; icacls "`cygpath -m "$p"`"; done


Thank you. (Again.)
1. Actually before reading this I had deleted both folders
(successfully, despite not being permitted entry into one
of them) and the re-ran the xinit installation with no
bother at all.
I'm guessing the Permissions glitch resulted from some local
recent accidental keypress or sequence.
2. icacls? Haven't got this though I have got getfacl; found icacl in
"Search packages" under libattica-devel and ng-spice-debuginfo?


$ /proc/cygdrive/c/WINDOWS/system32/icacls /?




--
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: Re: Black screen running startx

[Frank Eskesen via Cygwin]

Easy to see problem symptom: When running xinit, the full-screen window 
has a white border.


I have an older machine with an "ASUS NVIDIA GeForce GTX 770" graphics card.

The problem was either with the NVIDIA Windows display driver or some 
underlying Windows update. Fixing it was a problem:

- Reinstalling a back-level driver *did not* fix the problem.
- Deleting the device driver *did not* fix the problem.
At first, Windows installed a basic windows driver and xinit worked and 
the screen was visible. However, after a short time the window turned 
all white. Examining the "(Control Panel/Device manager)machine/Display 
adapters" showed that the NVIDIA driver had been reinstalled. I found 
(with some difficulty) a Windows tool (wushowhide.diagcab) that's 
*supposed* to prevent driver reinstalls. It found the NVIDIA driver in 
the brief window between when the driver was deleted and before the 
automatic reinstall but *did not* prevent the re-install. Additionally:
  - Control panel delete of all NVIDIA programs (including device 
driver) didn't work.
  - Renaming all "C:/Program Files/NVIDA*" and "C:/Program 
Files/X86/NVIDIA*" folders to "../xxNVIDIA*" folders didn't work.
  (Windows still found "restored" the useless driver from a 
DriverStore/Repository.)


> Disabling the NVIDIA driver finally fixed the problem. Drastic, but 
at least removing the video card wasn't required.


(Whew.)

On 3/16/2024 5:39 PM, Frank Eskesen wrote:

When I ran xinit, I got the following events in the Windows event log:
   Display driver nvlddmkm stopped responding and has successfully 
recovered.


Kernel diagnostic event: 
=

Fault bucket LKD_0x141_Tdr:6_IMAGE_nvlddmkm.sys_Kepler_3D, type 0
Event Name: LiveKernelEvent
Response: Not available
Cab Id: a6403500-eabe-4cd3-b903-6bb2b419deb1

Problem signature:
P1: 141
P2: 860f28aef050
P3: f805298bc9b8
P4: 0
P5: 0
P6: 10_0_19045
P7: 0_0
P8: 256_1
P9:
P10:

Attached files:
\\?\C:\WINDOWS\LiveKernelReports\WATCHDOG\WATCHDOG-20240316-1657.dmp
\\?\C:\WINDOWS\TEMP\WER-327258125-0.sysdata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA8C5.tmp.WERInternalMetadata.xml 


\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA8E5.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA8F8.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA956.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Kernel_141_6cdced420649f37203e03acc79a72eda67e51__cab_efab5333-8f8d-44e4-a528-6ae62b848c4d 



Analysis symbol:
Rechecking for solution: 0
Report Id: efab5333-8f8d-44e4-a528-6ae62b848c4d
Report Status: 268435456
Hashed bucket:
== 



Why this suddenly appeared is a mystery, but it's a Windows mystery. The
ReportArchive information summary is:
ReportDescription=A problem with your hardware caused Windows to stop 
working correctly.


So, the problem appears to in the Windows display driver. Please hold off
looking at this problem, at least until I can get more usable 
information.



--
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: Black screen running startx

[Frank Eskesen via Cygwin]

When I ran xinit, I got the following events in the Windows event log:
   Display driver nvlddmkm stopped responding and has successfully 
recovered.


Kernel diagnostic event: 
=

Fault bucket LKD_0x141_Tdr:6_IMAGE_nvlddmkm.sys_Kepler_3D, type 0
Event Name: LiveKernelEvent
Response: Not available
Cab Id: a6403500-eabe-4cd3-b903-6bb2b419deb1

Problem signature:
P1: 141
P2: 860f28aef050
P3: f805298bc9b8
P4: 0
P5: 0
P6: 10_0_19045
P7: 0_0
P8: 256_1
P9:
P10:

Attached files:
\\?\C:\WINDOWS\LiveKernelReports\WATCHDOG\WATCHDOG-20240316-1657.dmp
\\?\C:\WINDOWS\TEMP\WER-327258125-0.sysdata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA8C5.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA8E5.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA8F8.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA956.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Kernel_141_6cdced420649f37203e03acc79a72eda67e51__cab_efab5333-8f8d-44e4-a528-6ae62b848c4d

Analysis symbol:
Rechecking for solution: 0
Report Id: efab5333-8f8d-44e4-a528-6ae62b848c4d
Report Status: 268435456
Hashed bucket:
==

Why this suddenly appeared is a mystery, but it's a Windows mystery. The
ReportArchive information summary is:
ReportDescription=A problem with your hardware caused Windows to stop 
working correctly.


So, the problem appears to in the Windows display driver. Please hold off
looking at this problem, at least until I can get more usable information.

--
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: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Frank-Ulrich Sommer via Cygwin]

On 07.02.2024 20:27, Corinna Vinschen via Cygwin wrote:

On Feb  7 20:23, ASSI via Cygwin wrote:

Frank-Ulrich Sommer via Cygwin writes:

I'm trying to run cygsshd on my PC with Windows 11 and connect from a
linux machine. I have added the public key to
/cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link
from  /cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked
the access rights and mode of the .ssh directory (700 and belongs to
user xxx) and the authorized_keys file (600 and also belongs to user
xxx) and also of the home directory (had to change ownership).

Just bind mount instead of symlinking .ssh and everything should work.

Assuming you have installed CYgwin under your own account, that's even
better than utilizing "StrictModes"


Corinna



Ich decided to move the .ssh directory to /home/username/.ssh and edited nsswitch.conf to 
specify the home directory with "db_home: /home/%U" (all entries in this file 
were commented). Now sshd seems to work without deactivating strict mode. If I should 
still get problems with something else missing the .ssh directory in the WIndows Users 
directory I will try the bind mount.

I do not know how the .ssh got in /cygdrive/c/Users/... because I did not 
change anything manually.

Thanks for all the help!


--
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: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Frank-Ulrich Sommer via Cygwin]

On 06.02.2024 22:22, Brian Inglis via Cygwin wrote:

On 2024-02-05 18:36, Eliot Moss via Cygwin wrote:

On 2/5/2024 8:28 PM, Frank-Ulrich Sommer via Cygwin wrote:

On 05.02.2024 00:53, Frank-Ulrich Sommer via Cygwin wrote:

I'm trying to run cygsshd on my PC with Windows 11 and connect from a linux 
machine. I have added the public key to 
/cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link from  
/cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked the access 
rights and mode of the .ssh directory (700 and belongs to user xxx) and the 
authorized_keys file (600 and also belongs to user xxx) and also of the home 
directory (had to change ownership).


Change the symlink from Cygwin home to your home, as symlinks have a+rwx perms, 
so you can not use one for .ssh:

$ ln -sv `cygpath -aU "C:/Users/$USER"` /home/


Currently I'm reluctant to do this as my current cygwin home directory looks quite 
"clean" and does not contain hundreds of Windows files and subdirectories. I 
just added the link as the .ssh directory was automatically created as 
/cygdrive/c/Users/fus/.ssh and I wanted to have an easier access and avoid having two 
different .ssh directories which showed to be quite risky in the past.

Now I get the following strange messages:
[...]
Feb  5 00:35:50 X sshd: PID 2798: debug1: temporarily_use_uid: 
197609/197121 (e=18/18)
Feb  5 00:35:50 X sshd: PID 2798: debug1: trying public key file 
/home/xxx/.ssh/authorized_keys
Feb  5 00:35:50 X sshd: PID 2798: debug1: fd 5 clearing O_NONBLOCK
Feb  5 00:35:50 X sshd: PID 2798: Authentication refused: bad ownership or 
modes for directory /cygdrive/c/Users
Feb  5 00:35:50 X sshd: PID 2798: debug1: restore_uid: 18/18
[...]
Why is cygsshd complaining about the Windows "Users" directory and not about 
the directory of user xxx (/cygdrive/c/Users/xxx)? And how can I solve this?



Looking at the OpenSSH source code (on Github, not from Cygwin) I found a function 
"safe_path" that checks that the ownership and access modes for all path components are 
correct.  This relies on "platform_sys_dir_uid" which checks if a UID may own a system 
directory. The code checks for UID zero and might also accept an OS specific second value 
(PLATFORM_SYS_DIR_UID) but for Cygwin this seems not to be set. But I don't know where to find the 
source code for the exact version that is used in Cygwin and I'm unsure about build settings.


Run Cygwin setup and select package openssh Source checkbox to download the 
source package, or go to your Cygwin upstream mirror and download the source 
tarball shown in setup.ini prefixed with your nearest Cygwin mirror site e.g.

https://ftp.fau.de/cygwin/x86_64/release/openssh/openssh-9.6p1-1-src.tar.xz

Build settings are in the Cygwin package build control script definitions file 
openssh.cygport in the source tarball or build repo:

https://cygwin.com/cgit/cygwin-packages/openssh/tree/openssh.cygport

...
--disable-strip
   --with-kerberos5=/usr
   --libexecdir=/usr/sbin
   --with-xauth=/usr/bin/xauth
   --with-libedit
   --with-security-key-builtin


Thanks for that tip, I found and installed it and succeeded to build it with 
additional info in the error message (see below).

A comment defines this a safe path as follows:
"This is defined as all components of the path to the file must be owned by either 
the owner of the file or root and no directories must be group or world writable."



The "Users" directory is owned by "SYSTEM" (numeric: 18 according to stat) and 
only writable by Administrators and SYSTEM. The mode cygwin shows for /cygdrive/c/Users is 0750 
which should be OK.



So my question is: are "Administrators" and "SYSTEM" different users and does 
cygsshd accept SYSTEM (numeric 18) as a valid user who may own system directories? If the numeric 
ID is really 18 I can't see how this check can succeed but I'm not sure the code used in Cygwin is 
the same.


$ id SYSTEM
uid=18(SYSTEM) gid=18(SYSTEM) groups=544(Administrators),18(SYSTEM)


OK, I get the same on my system which seems to be Windows standard.

Administrators and SYSTEM are not the same.  And neither is exactly equivalent
to the concept of root in POSIX.  SYSTEM (in my experience) is used for things
like backup tools that needs access to almost every file. Administrators is for
system administration.  I don't have deep knowledge of all of this - others can
give a deeper / more nuanced answer.


Look at permissions at all levels:

$ lsattr -d ~/.ssh/;echo;ls -dl ~/.ssh/;echo;getfacl ~/.ssh/;\
    icacls `cygpath -m ~/.ssh`
 /home/BWI/.ssh/

drwx-- 1 $USER None 0 Mar  8  2023 /home/$USER/.ssh/

# file: /home/$USER/.ssh/
# owner: $USER
# group: None
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:other::---

...

Re: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Frank-Ulrich Sommer via Cygwin]

Looking at the OpenSSH source code (on Github, not from Cygwin) I found a function 
"safe_path" that checks that the ownership and access modes for all path components are 
correct.  This relies on "platform_sys_dir_uid" which checks if a UID may own a system 
directory. The code checks for UID zero and might also accept an OS specific second value 
(PLATFORM_SYS_DIR_UID) but for Cygwin this seems not to be set. But I don't know where to find the 
source code for the excat version that is used in Cygwin and I'm unsure about build settings.

A comment defines this a safe path as follows:
"This is defined as all components of the path to the file must be owned by either 
the owner of the file or root and no directories must be group or world writable."

The "Users" directory is owned by "SYSTEM" (numeric: 18 according to stat) and 
only writable by Administrators and SYSTEM. The mode cygwin shows for /cygdrive/c/Users is 0750 
which should be OK.

So my question is: are "Administrators" and "SYSTEM" different users and does 
cygsshd accept SYSTEM (numeric 18) as a valid user who may own system directories? If the numeric 
ID is really 18 I can't see how this check can succeed but I'm not sure the code used in Cygwin is 
the same.

On 05.02.2024 00:53, Frank-Ulrich Sommer via Cygwin wrote:

Hi,

I'm trying to run cygsshd on my PC with Windows 11 and connect from a linux 
machine. I have added the public key to 
/cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link from  
/cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked the access 
rights and mode of the .ssh directory (700 and belongs to user xxx) and the 
authorized_keys file (600 and also belongs to user xxx) and also of the home 
directory (had to change ownership).

Now I get the following strange messages:

[...]
Feb  5 00:35:50 X sshd: PID 2798: debug1: temporarily_use_uid: 
197609/197121 (e=18/18)
Feb  5 00:35:50 X sshd: PID 2798: debug1: trying public key file 
/home/xxx/.ssh/authorized_keys
Feb  5 00:35:50 X sshd: PID 2798: debug1: fd 5 clearing O_NONBLOCK
Feb  5 00:35:50 X sshd: PID 2798: Authentication refused: bad ownership or 
modes for directory /cygdrive/c/Users
Feb  5 00:35:50 X sshd: PID 2798: debug1: restore_uid: 18/18
[...]

Why is cygsshd complaining about the Windows "Users" directory and not about 
the directory of user xxx (/cygdrive/c/Users/xxx)? And how can I solve this?

Frank




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

cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Frank-Ulrich Sommer via Cygwin]

Hi,

I'm trying to run cygsshd on my PC with Windows 11 and connect from a linux 
machine. I have added the public key to 
/cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link from  
/cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked the access 
rights and mode of the .ssh directory (700 and belongs to user xxx) and the 
authorized_keys file (600 and also belongs to user xxx) and also of the home 
directory (had to change ownership).

Now I get the following strange messages:

[...]
Feb  5 00:35:50 X sshd: PID 2798: debug1: temporarily_use_uid: 
197609/197121 (e=18/18)
Feb  5 00:35:50 X sshd: PID 2798: debug1: trying public key file 
/home/xxx/.ssh/authorized_keys
Feb  5 00:35:50 X sshd: PID 2798: debug1: fd 5 clearing O_NONBLOCK
Feb  5 00:35:50 X sshd: PID 2798: Authentication refused: bad ownership or 
modes for directory /cygdrive/c/Users
Feb  5 00:35:50 X sshd: PID 2798: debug1: restore_uid: 18/18
[...]

Why is cygsshd complaining about the Windows "Users" directory and not about 
the directory of user xxx (/cygdrive/c/Users/xxx)? And how can I solve this?

Frank

--
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: Strange behavior when executing programs

[Frank Redeker via Cygwin]

Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen:

On Dec 12 14:09, Corinna Vinschen via Cygwin wrote:

On Dec 12 13:46, Frank Redeker via Cygwin wrote:

Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:

On Dec 12 11:21, Frank Redeker via Cygwin wrote:

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
[...]

However, a generic solution would be preferrable, and a local patch
to your scripts would be the better workaround for now.


Please test cygwin-3.5.0-0.30.g5ba5e09b9d39.  It contains a patch
trying to workaround the problem.


Thanks,
Corinna

Hello Corinna,

thanks for your patch. It works as expected.

$ uname -a
CYGWIN_NT-10.0-22000 W11-DEVELOP 3.5.0-0.30.g5ba5e09b9d39.x86_64 
2022-12-12 21:37 UTC x86_64 Cygwin


$ pwd
/cygdrive/s/ado

$ realpath msadox.dll
/cygdrive/s/ado/msadox.dll

$ sample.exe msadox.dll
[msadox.dll] -> [S:\ado\msadox.dll]


Frank


--
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: Strange behavior when executing programs

[Frank Redeker via Cygwin]

Am 12/13/2022 um 3:15 PM schrieb Corinna Vinschen:

On Dec 13 13:54, Frank Redeker via Cygwin wrote:



Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen:

On Dec 12 14:09, Corinna Vinschen via Cygwin wrote:

On Dec 12 13:46, Frank Redeker via Cygwin wrote:

Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:

On Dec 12 11:21, Frank Redeker via Cygwin wrote:

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
[...]

However, a generic solution would be preferrable, and a local patch
to your scripts would be the better workaround for now.


Please test cygwin-3.5.0-0.30.g5ba5e09b9d39.  It contains a patch
trying to workaround the problem.


Thanks,
Corinna

Hello Corinna,

I will try it out. Can you tell me where I can find the built cygwin.dll? Or
do I have to build the DLL myself.


https://cygwin.com/faq.html#faq.api.testrels ;)


Corinna

Hello Corrina,

I tried to install in fresh VM without success. (No AV installed and the 
Windows Firewall is off)


2022/12/13 17:04:42 Starting cygwin install, version 2.924
2022/12/13 17:04:42 User has backup/restore rights
2022/12/13 17:04:42 User has symlink creation right
2022/12/13 17:04:42 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 
2 No such file or directory
2022/12/13 17:04:42 Current Directory: 
D:\Program_Files_64\cygwin64\downloads
Could not open service McShield for query, start and stop. McAfee may 
not be installed, or we don't have access.

2022/12/13 17:04:49 source: download
2022/12/13 17:04:51 Selected local directory: 
D:\Program_Files_64\cygwin64\downloads

2022/12/13 17:04:55 net: Direct
Cached mirror list unavailable
User-Agent: default is "Cygwin-Setup/2.924 (Windows NT 
10.0.18362;Win64;0407;SymLinkPriv)"
2022/12/13 17:05:25 connection error: 12057 fetching 
https://cygwin.com/mirrors.lst

2022/12/13 17:05:25 mbox note: Could not download mirror sites list
Defaulting to empty mirror list
2022/12/13 17:11:52 net: Direct
2022/12/13 17:11:56 mbox : Are you sure you want to exit setup? Any 
current download or installation will be aborted.
2022/12/13 17:11:58 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 
2 No such file or directory

2022/12/13 17:11:58 Ending cygwin install

Maybe the stripped ProcMon logfile is helpful.


Frank
"Process Name","Operation","Path","Result","Detail"
"setup-x86_64.exe","TCP Connect","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 0, mss: 1460, sackopt: 0, 
tsopt: 0, wsopt: 0, rcvwin: 65535, rcvwinscale: 0, sndwinscale: 0, seqnum: 0, 
connid: 0"
"setup-x86_64.exe","TCP Send","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 171, startime: 8228070, 
endtime: 8228070, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 200, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> 
server2.sourceware.org:https","SUCCESS","Length: 200, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> 
xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> 
xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0"
"setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> 
xxx.static.arcor-ip.net:8000","SUCCESS","Len

Re: Strange behavior when executing programs

[Frank Redeker via Cygwin]

Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen:

On Dec 12 14:09, Corinna Vinschen via Cygwin wrote:

On Dec 12 13:46, Frank Redeker via Cygwin wrote:

Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:

On Dec 12 11:21, Frank Redeker via Cygwin wrote:

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
[...]

However, a generic solution would be preferrable, and a local patch
to your scripts would be the better workaround for now.


Please test cygwin-3.5.0-0.30.g5ba5e09b9d39.  It contains a patch
trying to workaround the problem.


Thanks,
Corinna

Hello Corinna,

I will try it out. Can you tell me where I can find the built 
cygwin.dll? Or do I have to build the DLL myself.


Frank


--
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: [EXTERNAL] Re: Strange behavior when executing programs

[Frank Redeker via Cygwin]

Am 12/12/2022 um 4:41 PM schrieb Corinna Vinschen via Cygwin:

On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:

Sorry about the earlier typos


(and, hence, I suppose for the purposes of the OP).


and, hence, I suppose, *would work* for the purposes of the OP.


Since realpath is supposed to resolve all symlinks,


I meant by default (the -P behavior).  If -s was asked, then the output would 
be corect.


Options are only available in realpath(1).  As for under the hood,
realpath(3) has no options so it can only return one of the
alternatives.


Corinna

I don't have a problem with *realpath* but with the fact that a native 
program in a cygwin or msys shell gives a different result than in a 
Windows CMD or older versions of cygwin and msys.


Consider the following simple sample unsing the WIN32 API. (Compiled 
with MinGW, Borland, Visual Studio, )


#include 
#include 

int main(int argc, char ** argv) {
   char buffer[PATH_MAX];

   argc--; argv++;
   if (argc) {
  char *   dummy;

  GetFullPathName(*argv, sizeof(buffer), buffer, );
  printf("[%s] -> [%s]\n", *argv, buffer);
   }

   return 0;
}

If I execute the program from inside CMD it gives the expected result.

S:\ado>sample msadox.dll
[msadox.dll] -> [S:\ado\msadox.dll]

From inside a bash the result depends on passed argument and/or the 
current working directory of the shell.


f.redeker@MIMIR-2 /cygdrive/s/ado
$ sample msadox.dll
[msadox.dll] -> [C:\Program Files\Common Files\System\ado\msadox.dll]

With Process Monitor I have observed that the shell does not execute the 
program directly, but starts a subshell and that subshell then starts 
the actual program.


The created Windows Process has as working directory not S:\ado but 
C:\Program Files\Common Files\System\ado.


But if the first argument of GetFullPathName() is a relative path, then 
Windows takes into account the in my eyes incorrect working directory. 
The same thing happens when you use GetCurrentDirectory() in your program.



Frank


--
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: Strange behavior when executing programs

[Frank Redeker via Cygwin]

Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:

On Dec 12 11:21, Frank Redeker via Cygwin wrote:

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msadox.dll


Is there any way to restore the old behavior. Since with the new behavior my
tests no longer work.


It's not easy.  If we remove the new behaviour entirely, we break
other scenarios which were broken in the old version.  While it
*seems* easy to fix your specific scenario, it will break again
as soon as the substitution drive is used inside a native symlink.

Virtual drive letters were always a problem and it doesn't get easier
with Windows functions not allowing to specify whether one wants to
follow symlinks or virt drives in inner path components or not.

Let's consider this problem again, but I don't see a quick and easy
solution.


Corinna

Hello Corinna, I am willing to create my own version, tailored to my needs.

It would be nice if you could provide me with the commit that was used 
to implement the new behavior. (I guess the change is found inside the

*git://sourceware.org/git/newlib-cygwin.git* repository)

Frank


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

Strange behavior when executing programs

[Frank Redeker via Cygwin]

Hello List,
I have a strange behavior when the executing a program in a shell. I'm 
on Windows 10 Version 22H2 (OS Build 19045.2251). The strange behavior 
occurs when the current directory is on a drive created with subst.


Originally I found the problem in a MSYS shell and already reported the 
problem here https://github.com/msys2/msys2.github.io/issues/234. In a 
reply someone asked me to check how it behaves under cygwin.


Here are the steps to reproduce the problem.

Inside a Windows CMD

C:\Users\f.redeker>subst s: "C:\Program Files\Common Files\System"
C:\Users\f.redeker>subst
S:\: => C:\Program Files\Common Files\System


On a computer with an older cygwin intallation

$ uname -a
CYGWIN_NT-6.1-WOW Mimir 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin

$ sh --version
GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>


This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/s/ado/msadox.dll


On a computer with a more actual version,

$ uname -a
CYGWIN_NT-10.0-19045 MIMIR-2 3.3.6-341.x86_64 2022-09-05 11:15 UTC 
x86_64 Cygwin


$ sh --version
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>


This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ pwd
/cygdrive/s/ado

$ realpath /cygdrive/s/ado/msadox.dll
/cygdrive/s/ado/msadox.dll

$ realpath msadox.dll
/cygdrive/c/Program Files/Common Files/System/ado/msadox.dll


Is there any way to restore the old behavior. Since with the new 
behavior my tests no longer work.


Mit freundlichen Grüßen / Best Regards

Frank Redeker

--
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: [ANNOUNCEMENT] Updated: irssi-1.4.2-1

[Frank Hedrich]

Marco Atzeri wrote:

> New version 1.4.2-1

>irssi

The command /notify -list in irssi makes the application crash. /notify (without
-list) works. This didn't happen in the previous version.

I get an irssi.exe.stackdump with Exception: STATUS_ACCESS_VIOLATION
(thread main), as standard user and as administrator.

This is in mintty with bash, with a current Cygwin (3.3.5-1) and current
Windows 11 with all updates installed respectively, everything 64-bit.

-- 
FH

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

Please add my key

[Frank Mertens]

Name: Frank Mertens
 BEGIN SSH2 PUBLIC KEY 
Comment: "2048-bit RSA, converted by fme@platypus from OpenSSH"
B3NzaC1yc2EDAQABAAABAQDdJFNvFmledOE/dmDipMMlVaMpcVOW4+txsJbVqt
/q09ditI2RkZMhntJwFDi7T7CbDLYmTfIiYxBgkTjlNu8GJ1gJDKVA8Ucz13gCkXZLykv/
R6eHtecEnGsvxYgi7Z3tCjphUHXGE7YAjNhx+luIA7CzosouvQKe1TKpTb8pof4Fl+LGnv
I9pgv0T9zvjLqkvpv5yqcKPrtL6X7cpNsVU3IoOEoE30y1MD1RRmy3Ji2f8tNIOxhQuUtl
1G3fqMOqdJ5V2gGke2/Ue2FzgccBedB8w2Mwry8b50LIkzMsQlftJAjmvNJVhCHW62jWT1
bAlHsiAr/cTPrFLHxRufiB
 END SSH2 PUBLIC KEY 

Link/$PATH interaction problem

[Frank Eske via Cygwin]

Similar to December's "cygwin1.dll > 3.1.4 Program execution fails if
(WSL-)symlink exists and is present in PATH", but it's still present in
3.1.6 and 3.1.7. While I can revert back to 3.1.4 (and 3.1.2,) links I have
created since then do not show up as links and are listed as owned by
UnknownUser and UnknownGroup. I have dozens of such links scattered
throughout, making revert testing impractical.

I keep scripts in /home/userid/bat, which is a link, and compiled programs
in /home/userid/bin, which is a simple directory. My PATH begins with
.:/home/userid/bat:/home/userid/bin:... Problems started when I changed the
/home/userid/bat link. After the change, none of the programs in
/home/userid/bin worked. They would just return. Running them with gdb,
they would fail to start (During startup program exited with code
0xc79) /usr/bin/ programs continued to operate normally.

My relevant links are as follows:
/C -> /cygdrive/c
/home/data -> /C/home/data
/home/userid/bat -> /home/data/home/bat

Currently my /home/userid/bat link is owned by Administrators:None, as
restored by backup software. If I replace it, programs in /home/userid/bin
do not run. If I add ANY other new link to the beginning of $PATH, none of
my compiled programs anywhere run. Adding at the end does not cause any
detectable problem.

With a PATH containing a beginning link: ldd ~/bin/program yields:
   ntdll.dll => ,,,
   KERNEL32.DLL => ...
   KERNELBASE.dll => ...

Without leading link items (except for the restored link), ldd
~/bin/program additionally yields:
   cygwin1.dll => ,,,
   (and sometimes more)

Let me know if you need further information.
--
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: "ls" sorts wrongly if given large number of files

[Frank-Ulrich Sommer via Cygwin]

Am 06.01.2021 um 19:17 schrieb Kamran via Cygwin:

Hi all

"ls" (version 8.26) sorts wrongly if given large number of files via "find" or 
"xargs"

For example:

find -type f -exec ls -oS -h {} +

OR

find -type f -print0 | xargs -0r ls -oS -h

Gives following data. Sorry for the long listing, and wrapped lines. But search for 
"setup.ini" which is about 17 MB, it is sorted AFTER very small files.

In fact it seams that sorting is restarted from that file (subsequent files are again sorted). Note 
also that removing "-h" from "ls" command lines results in the same problem.

(output is trimmed to remove unnecessary data, i.e. perms/user/date-time, but 
order is the same)

 26M ./release/gcc/gcc-core/gcc-core-10.2.0-1.tar.xz
 24M ./release/binutils/binutils-2.34+1git.de9c1b7cfe-1.tar.xz
[...]
108 ./release/python2/python/python-2.7.16-1.tar.xz
 108 ./release/python-gobject/python-gobject-2.28.7-1.tar.xz
  46 ./release/tcl-tk/tcltk/tcltk-20120206-1.tar.bz2
  32 ./release/man-db/man/man-2.6.7-2.tar.xz
  32 ./release/popt/popt-1.16-2.tar.xz
  32 ./release/procps-ng/procps/procps-3.3.10-1.tar.xz
 17M ./setup.ini
5.7M ./release/vim/vim-common/vim-common-8.2.0486-1.tar.xz
4.6M ./release/w32api-headers/w32api-headers-8.0.0-1.tar.xz
1.8M ./release/vim/vim-doc/vim-doc-8.2.0486-1.tar.xz
[...]
16K ./release/xeyes/xeyes-1.1.2-1.tar.xz
 15K ./release/xf86-video-dummy/xf86-video-dummy-0.3.8-1.tar.xz
 12K ./release/util-linux/libuuid1/libuuid1-2.33.1-2.tar.xz


xargs uses multiple calls to ls and find calls ls once for each matching file 
so in the two mentioned cases ls will not get to see the full list and thus 
can't sort all the files. This is the expected bahviour and not special to 
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: xterm tab key (temporarily) locks keyboard

[Frank Eske via Cygwin]

There may be some other key or key combination on the left side of the
keyboard that's doing this also. While the tab key can reproducibly cause
it, some other key combination might also.

Since my bash version is Jan 27, 2017 and none of my .bash scripts have
changed recently, xterm (Sep 20, 2020) seems like the most likely culprit.
I did create a .fonts file for experimentation which is just now removed.
(It's too early to tell whether that somehow created this problem.)

On Sun, Oct 18, 2020 at 2:07 PM Frank Eske  wrote:

> If the tab key is entered as the first character running the bash shell on
> an xterm terminal, the keyboard temporarily locks. Control-C writes ^C but
> doesn't unlock it. This doesn't happen on Fedora. It also doesn't lock if a
> space is typed first.
>
> This occurs whether or not the xterm console is in an X environment.
>
> For some reason I seem to accidentally do this a lot more often than I'd
> like, so it's a real nuisance. I checked this mailing list for the last
> four months and couldn't find " tab" or a useful "tab ", I find it
> difficult to believe that I'm the first to see this, so maybe there's
> something I changed that's making this happen. Any advice on what that
> might be?
>
>
>
--
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

xterm tab key (temporarily) locks keyboard

[Frank Eske via Cygwin]

If the tab key is entered as the first character running the bash shell on
an xterm terminal, the keyboard temporarily locks. Control-C writes ^C but
doesn't unlock it. This doesn't happen on Fedora. It also doesn't lock if a
space is typed first.

This occurs whether or not the xterm console is in an X environment.

For some reason I seem to accidentally do this a lot more often than I'd
like, so it's a real nuisance. I checked this mailing list for the last
four months and couldn't find " tab" or a useful "tab ", I find it
difficult to believe that I'm the first to see this, so maybe there's
something I changed that's making this happen. Any advice on what that
might be?
--
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

Cygwin X server accepts xfixes version 5.0 but doesn't handle xcb_xfixes_hide_cursor

[Frank Eske via Cygwin]

I'm building an XCB-based application that uses xcb_xfixes_hide_cursor. The
X server reports back version 5.0 in xcb_fixes_query_version_reply and
accepts xcb_xfixes_hide_cursor requests, but does not hide the cursor. When
omitting the xcb_fixes_query_version operation, the xcb_xfixes_hide_cursor
is (properly) rejected. Compiling and running the same program under
Fedora, the cursor is hidden when running natively. When running an ssh
remote xterm to Fedora, the hide_cursor again does nothing.

The associated X11/extensions/Xfixes.h XFixesHideCursor() works
identically. It fails to do anything but does not report any error
indication.

When testing this on Fedora, I also noticed that xterm hides the cursor in
exactly the same manner I want for my application, and doesn't on Cygwin
(where it always remains visible.) That is, typing hides the cursor and
cursor movement shows it again. This should eliminate the need for a test
case which, because of all the ancillary setup needed, would be quite large.

Possibly the simplest fix would be to properly report back the version of
Xfixes you actually support, document that restriction at least in the
include file, and reject the Xfixes extension requests you don't handle. As
an aside, almost every other X feature I've tried to use has worked
identically on Cygwin and Fedora, usage bugs included.

Note that there is probably a work-around for this missing function by
creating a blank cursor and using that instead of hide_cursor.
--
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: changed behaviour for "cygcheck -p "

[Frank Ch. Eigler via Cygwin]

Hi -

> > It seems there is a new escape system that is fooling
> > the search engine
> > $ cygcheck -p 'bin/mutt'
> https://cygwin.com/packages/

I suspect it's not new, but yes, urlescaped %XY characters are not
correctly handled in package-grep.cgi.  Until it's fixed, you can use
dots instead of slashes, for example.

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

openssh 8.1p1-1 performance regression

[Frank Eske]

I recently updated my Cygwin installation and ran into a strange performance
problem. At least part of the problem was introduced between openssh 8.1p1-1
and 8.0p1-2.

Here's one way to reproduce the problem:
1) Start Cygwin X using "xinit something -- -clipboard"
   File something contains at least:
   xterm &
   exec fvwm

2) Connect to a remote host. The remote host can be running Linux or Windows
   Cygwin with sshd server. The connect command sequence is:
   xhost +machine
   xterm -e ssh -Y -o ServerAliveInterval=10 machine -l userid &
   Where machine is the remote machine name and userid the remote
userid.
   Call this xterm window "window 1."

   From window 1, use "xterm &" to create another remote terminal window.
   Call this second remote xterm window "window 2."

3) Run a simple performance test:
   a) Repeatedly hit the enter key until the window only contains command
  prompts.
   b) Enter "#" (or anything else, it's just a dummy command)
   c) Hold the enter key and note the speed that the dummy command scrolls
up
  the windows. Window 1 scrolls up rapidly. Window 2 scrolls up slowly.

Notes:
   It also takes longer for window 2 to appear than it used to.

   Try "man bash" or "view some-reasonably-sized-text-file". Try page
up/down
   or arrow up/down. Somewhat surprisingly, there is no detectable
difference
   between the windows. Both have zero latency.

4) Modify your Cygwin installation, back-leveling openssh to 8.0p1-2, and
repeat
   the first performance test. There's no difference between the windows,
and
   the second window start up time improves.

I might not have noticed this problem except that I use a (self-written)
program that uses ncurses for screen update operations. It performed way
worse
than the command roll-up. However, even with the back level openssh, some
latency exists where I don't think any existed before. I haven't found any
Cygwin-related reason for this. I looked at packages xorg-server, xinit, and
xterm, finding no performance changes when back-leveling them. Package
ncurses
was unchanged since my last update.

--
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: rsync and ls -lR slow for directories with many files

[Frank-Ulrich Sommer]

Thank you for the suggestions. The Linux disk is newer and does not use SMR, 
but for reading there should not be a big difference.

The windows box is running standalone without AD or anything similar. 
Concerning perms and metadata I must admit that I do not know what to look for.

As I did not know how to capture output of rsync on the remote side I did 
strace the "ls -lR", but I could not detect anything that looked funny. I fear 
if something creates more disk accesses than necessary it must be within the 
system calls.

Then I tried to disable as many features of rsync as possible and used the 
following options:
-avx
--stats
--whole-file
--no-perms
--no-owner
--no-group
--no-devices
--no-specials
--no-acls
--no-xattrs

but rsync did not get faster.

I'm sorry to admit that the ultimate solution does not use Cygwin any more. I'm 
now using a Windows share and connect to that share from my Linux server with 
cifs and autofs. rsync then runs on the linux machine and accesses that share 
(due to --whole-file this should not cause problems).

rsync without any changed files directly after booting both systems (both 
caches are empty) now takes 91s instead of 42m.





Am 5. Januar 2020 22:22:35 MEZ schrieb Stephen John Smoogen :
>On Sat, 4 Jan 2020 at 17:16,  wrote:
>>
>> I am running rsync on a small linux server to synchronize files in
>one directory and its subdirectories from Windows (using sshd from
>Cygwin) to this server for backup purposes. The directory contains
>almost 1 TB of images and videos in about 160k files on a slow disk
>(Seagate Archive 8TB with SMR) with NTFS.
>
>I am not sure if the Linux box has the slow disk or the Windows box
>has the slow disk.
>
>> Even if there are no changes and whith whole file transfers rsync
>takes about 45 minutes to come to this conclusion.
>> I am using the following command line on the linux server:
>>
>> rsync -avx --stats --whole-file --no-perms --no-owner --no-group
>@: 
>>
>> As rsync was only transferring a small number of bytes and gave no
>clue to the cause for being so slow and as rsync should only need
>filenames, dates and sizes I did a "ls -lR|wc" on both systems. On the
>linux server this took about 1 minute (only slightly faster magnetic
>disk, empty read cache at start) and doing the same on cygwin took
>almost as long as rsync (over 40 minutes). Using Windows Explorer
>(after a reboot to guarantee that the cache is empty) to get the total
>number of files and the total size took only a few seconds. Reading all
>file sizes with Treesize also took less than one minute. As ls -lR
>needs the same information I would have expected it to take the same
>time.
>
>
>I would add a bunch of verbose to the rsync to see what it is doing.
>(I don't recommend sending that to the list as it will be a lot of
>data.. but maybe an excerpt) I am expecting it is spending a lot of
>time getting the metadata off of one of the disks and mapping it to
>Unix permissions then comparing if those items are the same on the
>other side. Each one of those is going to be a separate action which
>on a slow drive may be a spinup/get-data/spindown cycle to make it
>even slower.
>
>I would then check to see if perms and metadata on that directory
>'look sane' (this is highly dependent on your environment.. if you
>have an AD server giving out perms it will look different from other
>things.) If the lookups for mapping metadata permissions is having to
>ping an AD server or some sort of other network lookup that is going
>to also slow down things.
>
>Sorry I don't have any 'fixes'. I have always found large rsync
>between Windows and Unix to be slow.
>
>> Runnin "ls -lR" a second time on Cygwin is fast as lightning as it
>only takes less than 30s.
>>
>> Is there any way to get ls -lR or better rsync as fast as listing the
>directory with Windows tools?
>>
>> Frank
>>
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.
>> --
>> 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
>>
>
>
>-- 
>Stephen J Smoogen.
>
>--
>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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--
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: Unexpected behavior from cygpath command

[Frank Redeker]

Am 12.11.2019 um 23:16 schrieb Alfred von Campe:
> I have two almost identical build servers, but cygpath is not behaving as 
> expected on one of them.  Here is the output from the “good” build server:
> 
>   $ cygpath.exe —version | head -1
>   cygpath (cygwin) 2.11.2
>   
>   $ cygpath -d 'E:\Program Files (x86)\IAR Systems'
>   E:\PROGRA~1\IARSYS~1
> 
> Cygpath has correctly converted the given path to DOS (8.3) format as 
> expected. Here is the output from the “bad” build server.
> 
>   $ cygpath.exe —version | head -1
>   cygpath (cygwin) 2.11.1
> 
>   $ cygpath -d 'E:\Program Files (x86)\IAR Systems'
>   E:\Program Files (x86)\IAR Systems
> 
> Why is cygpath returning the same path passed in?  Oh wait, it’s running a 
> slightly older version (2.11.1 vs 2.11.2).  Perhaps there was a bug in the 
> earlier version.  Let me update the Cygwin installation and try again:
> 
>   $ cygpath —version | head -1
>   cygpath (cygwin) 3.1.0
> 
>   $ cygpath -d 'E:\Program Files (x86)\IAR Systems'
>   E:\Program Files (x86)\IAR Systems
> 
> WTF?  Why is it still doing this?  Can there be a global config setting that 
> affects cygpath’s behavior?  Hmm, let me try a different approach:
> 
>   $ cygpath -d "$(cygpath -u 'E:\Program Files (x86)\IAR Systems')"
>   E:\PROGRA~1\IARSYS~1
> 
> Hey, cygpath can convert to DOS paths on this system after all, just not when 
> it’s given a Windows path.  Can anyone explain this behavior?
> 
> Alfred
Hello, Alfred,

I think on both systems the handling of 8.3 names is configured
differently. You can check this with the Window command fsutil. (This
command requires elevated permissions)

I get the following output on my system.

C:\WINDOWS\system32>fsutil 8dot3name query d:
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2 (Per volume setting - the default).

Based on the above settings, 8dot3 name creation is enabled on d:


You can also change the handling of 8.3 names using this command. See
flsutil 8dot3name help

C:\WINDOWS\system32>fsutil 8dot3name help
 8DOT3NAME Commands Supported 

query   Query the current setting for the shortname behaviour on the system
scanScan for impacted registry entries
set Change the setting that controls the shortname behavior on the
system
strip   Remove the shortnames for all files within a directory


Greetings

Frank

--
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: winsymlinks:nativestrict and Windows 10

[Frank Redeker]

Am 19.03.2019 um 15:23 schrieb LRN:
> ... SNIP ...
> 
> Devmode + SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE is the only way to
> create symlinks without being Administrator (that i know of). You can't just
> give some extra privileges to your non-administrator account. I know, i've 
> tried.

On Windows 10 Pro (1809) this works for me for with a non-administrator
account.

I just added the SeCreateSymbolicLinkPrivilege to my normal user account
and was able to use mklink without any problems.


Frank

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

Does cygwin E-mail list still work?

[Frank Farance]

Hi, I haven't seen any E-mail traffic since 2018-09-11.  Is the list still 
active?  Did I get unsubscribed?

Frank Farance


--
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: speeding up a paste operation

[Frank Redeker]

Am 25.08.2018 um 02:10 schrieb Lee:
> On 8/24/18, James Darnley wrote:
>> On 2018-08-25 01:30, Lee wrote:
>>> In retrospect, I should have created the file some other way, but still..
>>> - grab the top 1M hosts from from
>>> http://s3-us-west-1.amazonaws.com/umbrella-static/index.html
>>> - open w/ libreoffice
>>> - select the host name column, right click & select copy (all 1 million
>>> lines)
>>> - (mintty 2.9.0 window already open) vi /tmp/hosts
>>> - i  (get into insert mode)
>>> - right click (which I have set to "paste")
>>>
>>> data is still scrolling by & it's not even up to 100K lines yet :(
>>>
>>> Is there some way to make a paste operation faster in mintty (or vim
>>> or whatever the slowpoke is)?
>>
>> There's a utility called getclip which put the clipboard onto stdout.
>> Direct that into a file and you should get the same result, excluding
>> Vim's indentation.  Probably doesn't use the tty in anyway.
> 
> Is getclip different from
>   cat > /tmp/hosts
>   
> 
> at least 'cat > /tmp/hosts' that goes faster than I can read.  But
> while that's running I can open notepad, paste the 1M lines in there,
> save to \cygwin\tmp\doshosts, open another mintty window & dos2unix
> /tmp/doshosts -- all that before the  finishes :(
> 
> Thanks,
> LeeHi Lee,

what about 'cp /dev/clipbord /tmp/hosts'?


Frank

--
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: My delayed complaint about spam on this list

[Frank Farance]

On 2018-06-05 20:04, Steven Penny wrote:

[...]
If OP is suggesting people can only reply if they are subscribed, then I am not 
a fan of that.


No, I'm not suggesting that one must be subscribed, I'm pointing out that if 
one wants to have a back and forth discussion (in a practical sense), some 
kinda registration/subscription system is necessary.  What I like about the 
present format of this list is: it's just E-mail, there aren't bulletin board 
web interfaces to forces the fragmentation of the discussion into separate 
threads, with cygwin I can see the discussion threads based upon Subject line.

Someone suggested a moderator (or multiple moderators) that would approve 
messages from outsiders.  That sounds like the easiest approach because it 
anyone can write to the list and there would be just a short delay for those 
people who aren't subscribers, but the main benefit would be the lack of spam.

I'm not tied to any technology, and I'm happy to have heard some more 
discussion, which better informed me about some of the Use Cases I was unaware 
of.

So here's my question (and it assumes that there would be volunteer(s) to 
moderate):

Question: "Would a moderation system work where subscribers could send messages 
directly, but non-subscribers would need a moderator to approve the message?"

If that is acceptable, then the next step would be to find a couple volunteers.

Your thoughts?

-FF

--
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: My delayed complaint about spam on this list

[Frank Farance]

On 2018-06-04 15:47, James Darnley wrote:


It isn't very nice to put "please email cygwin@cygwin.com" in error and warning messages 
then deny people the opportunity to send the email. "Please register first" is annoying 
as shit.  I have certainly not reported bugs to lists that make me do that.  The same applies to 
bug trackers.

> If you would like to reply to me, please send your response to me directly, 
DO NOT SEND TO THE LIST.  I will summarize back to the list. (Think: Old-School 
1980s USENET unix-wizards kinda framework.)

No thanks.  I wish to discuss this openly.


James-

First, my offer to have responses sent to me was a courtesy to the list ... 
some people would prefer to have this kind of Mailing List Mechanics discussion 
off line.  No problem having it discussed openly, I'm fine with that, too.

Second, as a mailing list admin myself, at some time we're going to have to 
deal with spam as some of the members E-mail systems will start tagging normal 
cygwin stuff as spam, which is the kind of stuff members don't have control 
over in medium-to-large organizations.  Again, I've heard all these 
*legitimate* concerns over several decades.

Third, I believe a registration mechanism (just your E-mail address) is 
necessary for discussion: How would you be getting follow-up messages if you're 
not on the list?  And E-mail clients may prefer Reply-To-List rather than 
Reply-All, which means even if people were CCing you, at some point you start 
missing discussion from others.

So given the choice between:

(1) getting rid of spam by restricting senders to members of the list (which, 
as you state, might lose people like you)

versus

(2) reducing spam for the 1500 members on the list (yet still lose you because 
you need to become a member of the list to see the responses from others),

THEN: in both cases we still wind up losing you (either you don't give your 
E-mail address to the list server or you're not included in the follow-up 
E-mails because you're not a member), ... YET in the latter case we reduce spam 
...

THUS, cygwin should restrict sending to just the members because (1) it will 
reduce spam, and (2) we're still going to lose people like you who don't want 
to put their name on the list - regardless of which spam reduction mechanisms 
is chosen.

Make sense?

-FF

--
__
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: GitForWindows vs. Cygwin

[Frank Fesevur]

2018-03-20 23:52 GMT+01:00 KARL BOTTS:
> Can anyone enlighten me about the relationship of "Git for Windows" to
> Cygwin?

Depends on how you define "relationship". Tony summed it up very nicely.

> I have no intention to use GFW myself: I use Cygwin git.  But now other people
> around here are discovering GitHub, MSysGit and or GitForWindows.  Pretty
> soon, we are going to wind up with multiple git flavors installed on the same
> host, which worries me.

I use the Cygwin based git tools (tig most of the time) as my main
client, but also use Git for Windows and its tig, WSL based and real
Ubuntu, the builtin git client in Visual Studio and VSCode. I often
combine them in one project, for instance use VS for the simple and
easy commit, use the Cygwin command line for more advance stuff and to
push and pull (because I mainly use SSH).

The **real caveat** is to get your line endings right. You need that
figured out in any multi platform environment, and combining Windows
bases git and Cygwin based git is exactly that. Cygwin and Ubuntu
default to LF. Git for Windows and the VS clients default to CRLF.

We use "git config --global core.autocrlf false" and combine that with
a proper .gitattributes and .editorconfig file. So far that works
quite well for us.

Hope it helps,
Frank

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

chere (=> windows explorer context menu) not working with German umlaut in Path

[Josef Frank]

The "chere" package installs an entry in the windows explorer context menu to 
open a mintty window running bash at an arbitrary location. 

However the context menu entry "Bash prompt here" does not work, when the 
directory path contains a German umlaut in any position. E.g.: using it for 
c:/temp/ö results in a Bash prompt opened in _c:/temp_, while opening a windows 
cmd prompt via context menu also works with umlauts in the path.

How do I resolve this issue?

FYI:

1. created registry entry is c:\opt\cygwin\bin\mintty.exe -e /bin/xhere 
/bin/bash.exe "%L" (in extended context menu "%L" is replaced by "%V"; but this 
also does not work)

2. locale setting in cygwin: LANG=de_DE.UTF-8

3. File system is NTFS. Therefore file names are claimed to be stored in 
"Unicode", whatever this means in the respective documentation (Windows Dev 
Center description of encoding for file 
names[https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748%28v=vs.85%29.aspx])

4. Codepage in CMD-window: 850 (according to powershell command 
[System.Text.Encoding]::Default)

5. Windows codepage: 1252

6. All three programs (windows explorer, cmd.exe, bash in mintty) show the 
umlaut in consistent manner despite different encodings

7. Renaming files is not possible as the problem mainly arises on network 
drives with folders/files that are a) referred to by lots of links (symbolic as 
well as windows shortcuts) and b) owned/shared by multiple different users

Greatly would appreciate help
Thanks in advance
JF


--
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: setup's response to a "corrupt local copy"

[Frank Redeker]

Am 16.12.2017 um 05:00 schrieb Steven Penny:
> On Fri, 15 Dec 2017 09:50:44, Vince Rice wrote:
>> It's my computer. I don't want setup (or anything else) replacing
>> files on it
>> it doesn't know about without at least asking whether that's what I
>> want it to
>> do. Setup's current behavior is exactly what it should be, IMO. If, as
>> has
>> been mentioned, someone wants to offer an *option* to replace, either
>> with or
>> without a question, then great. But the default should be to leave
>> something
>> it doesn't know about alone.
> 
> Thankfully we dont need your opinion on this matter, as we can simply
> fall back
> to facts, as I will now do. Let us bring some sanity to this thread,
> shall we?

Hello Steven Penny,

This is exactly the disagreeable tone in most Linux forums that keeps
people from switching from Windows to Linux. In almost all the threads I
read you here, you get personal.

> 
> Exhibit A
> 
> Package manager: APT
> Reference distro: Lubuntu http://lubuntu.me
> Cache: /var/cache/apt
> 
> Exhibit B
> 
> Package manager: DNF
> Reference distro: Fedora http://spins.fedoraproject.org/lxde
> Cache: /var/cache/dnf
> Option: keepcache=True
> 
> Exhibit C
> =
> Package manager: ZYpp
> Reference distro: Gecko LXQt http://geckolinux.github.io
> Cache: /var/cache/zypp
> Option: --keep-packages
> 
> In all cases, these package managers remove invalid archives without
> warning.
> Why should setup.exe be any different? I eagerly await your referenced and
> reasoned rebuttal.
> 

If 100 people jump off the bridge, will you jump after them? Who says
that automatic deletion without warning is the only true solution? You?

I agree with Vince on that. If setup. exe detects that a packet is
invalid, it should ask what to do with it instead of deleting it silently.


--
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: [ANNOUNCEMENT] python-sphinx 1.6.5-1

[Frank Fesevur]

2017-11-27 7:39 GMT+01:00 Yaakov Selkowitz:
> The following packages have been uploaded to the Cygwin distribution:
>
> * python2-alabaster-0.7.10-1
> * python2-babel-2.5.1-1
> * python2-imagesize-0.7.1-1
> * python2-jinja2-2.9.6-1
> * python2-pytz-2017.3-1
> * python2-snowballstemmer-1.2.1-1
> * python2-sphinx-1.6.5-1
> * python2-sphinxcontrib-websupport-1.0.1-1
> * python2-sphinx_rtd_theme-0.2.4-1
> * python2-sqlalchemy-1.1.15-1
> * python2-typing-3.6.2-1
> * python2-whoosh-2.7.4-1

Sphinx worked fine for many years on my pc, but after upgrading today
it is doesn't work anymore.

$ make html
Makefile:12: *** The 'sphinx-build' command was not found. Make sure
you have Sphinx installed, then set the SPHINXBUILD environment
variable to point to the full path of the 'sphinx-build' executable.
Alternatively you can add the directory with the executable to your
PATH. If you don't have Sphinx installed, grab it from
http://sphinx-doc.org/.  Stop.

I tried to reinstall the python2-sphinx package from setup.exe but
without any success.

Indeed, in /bin there is no sphinx-build or sphinx-quickstart.

Any thoughts?

Regards,
Frank

--
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: Cygwin alongside WSL

[Frank Fesevur]

2017-10-23 14:38 GMT+02:00 KARL BOTTS:
> Does anybody have any concrete experience using Windows Subsystem for Linux
> (hence WSL) on the same machine, alongside Cygwin?

I'm using them both without much problems (on Creator Update, not on
Fall Creator Update yet). I use them only for the command line. As
mentioned the CMD is not the best, but it gets the job done. I am also
looking into combining mintty and wsl, which takes some effort.

Since the architecture is much different, wsl is much faster and has
all the good stuff from the official Ubuntu repositories. But Cygwin
is available on Win7 and on servers, and Cygwin has cygrunsrv, which
wsl both lacks.

And I use 'noacl' on my /cygdrive mounts. WSL lack something like that
as well. That is really a big thing to me. I don't want a bash-script
to mess up my file permissions, especially not on network drives where
permissions can be crucial. WSL cannot mount network drives, at least
in the version I'm using.

I don't see myself choosing sides any time soon. Cygwin is still my
favorite and most used.

Regards,
Frank

--
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 get 'Normal' (or higher) version of (x86) vim?

[Frank Slootweg via cygwin]

I currently have vim version 8.0.596 from the (x64) package
"vim-8.0.0596-1 - vim: Vi IMproved - enhanced vi editor".

'vi --version' says:

"VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May 12 2017 11:38:40)
 Included patches: 1-596
 Modified by <cygwin@cygwin.com>
 Compiled by <cygwin@cygwin.com>
 Small version without GUI.  Features included (+) or not (-):"

From other threads on this list, I understand that vim should at least
be the 'Normal' version or even the 'Huge' version. Or is that only the
case for the x86_64 package? (I have a 64-bit computer/OS (Windows 8.1),
but - at least for the time being - I would like to keep Cygwin at x86.)

I need some options which are in the 'Normal' version, but not in my
current 'Small' version, specifically 'cryptv' and 'comments'

Is there another or earlier package which I can install to get the
'Normal' (or higher) version of vim?

Thanks in advance for any and all responses.

Frank

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

dd -- bs>=2G, error writing to /dev/null - possible bug? (win7; coreutils 8.26)

[Josef Frank]

Dear all,


dd utility has problems to write to /dev/null with bs>=2^31,
while bs<2^31 is ok.

Increasing bs further to 2^33 leads to extended error message

For description see below


jf




Steps to reproduce:


$ dd if=/dev/zero of=/dev/null bs=2147483647 count=1
1+0 records in
1+0 records out
2147483647 bytes (2.1 GB, 2.0 GiB) copied, 0.522774 s, 4.1 GB/s


$ dd if=/dev/zero of=/dev/null bs=2147483648 count=1
dd: error writing '/dev/null'
1+0 records in
0+0 records out
0 bytes copied, 0.517421 s, 0.0 kB/s


$ dd if=/dev/zero of=/dev/null bs=8589934591 count=1
dd: error writing '/dev/null'
1+0 records in
0+0 records out
0 bytes copied, 2.13474 s, 0.0 kB/s


$ dd if=/dev/zero of=/dev/null bs=8589934592 count=1
dd: error writing '/dev/null': No space left on device
1+0 records in
0+0 records out
0 bytes copied, 2.08004 s, 0.0 kB/s



In contrast the following lines (also coreutils 8.26) run fine (without
reporting any error):

head -c 2147483648 /dev/zero > /dev/null

head -c 8589934592 /dev/zero > /dev/null




Configuration:

Applies to several different machines with different amounts of main 
memory (up to 32GB, >24GB available), and sufficient free space on 
/var/tmp (100-180GB), all using Windows 7



$ uname -a
CYGWIN_NT-6.1 rab 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64 Cygwin


$ dd --version
dd (coreutils) 8.26
Packaged by Cygwin (8.26-2)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, and Stuart Kemp.


$ cygcheck dd
Found: C:\cygwin64\bin\dd.exe
Found: C:\cygwin64\bin\dd.exe
C:\cygwin64\bin\dd.exe
  C:\cygwin64\bin\cygwin1.dll
C:\windows\system32\KERNEL32.dll
  C:\windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
  C:\windows\system32\ntdll.dll
  C:\windows\system32\KERNELBASE.dll
  C:\windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-File-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-String-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
  C:\windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
  C:\cygwin64\bin\cygintl-8.dll
C:\cygwin64\bin\cygiconv-2.dll

--
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] Updated: shutdown 2.0-2

[Frank Fesevur]

Hi,

I've just updated the version of shutdown to v2.0-2 and it can be found at
a server near you.

This release fixes a build issue in the package. The 64-bit package actually
contained a 32-bit shutdown.exe
https://cygwin.com/ml/cygwin/2017-01/msg00194.html

FULL CHANGELOG (since shutdown-1.10-1)
==

* Added --install to install Windows Updates during shutdown/reboot.

  The InitiateShutdown() Windows API call is used for this. This function is
  only available from Windows 6.0 (aka Vista or Server 2008) or higher.
  To assure backwards compatibility with WinXP and Server 2003,
  InitiateShutdown() is loaded dynamically at runtime. Since Cygwin 2.6
  support for Windows XP and Server 2003 has been dropped, so this backward
  compatibility will be removed in a future release.

* Added --hybrid to shutdown in hybrid mode. Hybrid is the default shutdown
  method with shutting down with the UI of Windows 8.x and higher.

* The default shutdown messages will give more information on what is about
  to happen.

* User can supply his own shutdown message on the command line.

Enjoy!

Regards,
Frank

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

Updated: shutdown 2.0-2

[Frank Fesevur]

Hi,

I've just updated the version of shutdown to v2.0-2 and it can be found at
a server near you.

This release fixes a build issue in the package. The 64-bit package actually
contained a 32-bit shutdown.exe
https://cygwin.com/ml/cygwin/2017-01/msg00194.html

FULL CHANGELOG (since shutdown-1.10-1)
==

* Added --install to install Windows Updates during shutdown/reboot.

  The InitiateShutdown() Windows API call is used for this. This function is
  only available from Windows 6.0 (aka Vista or Server 2008) or higher.
  To assure backwards compatibility with WinXP and Server 2003,
  InitiateShutdown() is loaded dynamically at runtime. Since Cygwin 2.6
  support for Windows XP and Server 2003 has been dropped, so this backward
  compatibility will be removed in a future release.

* Added --hybrid to shutdown in hybrid mode. Hybrid is the default shutdown
  method with shutting down with the UI of Windows 8.x and higher.

* The default shutdown messages will give more information on what is about
  to happen.

* User can supply his own shutdown message on the command line.

Enjoy!

Regards,
Frank

Re: [ANNOUNCEMENT] Updated: shutdown 2.0-1

[Frank Fesevur]

2017-01-16 18:52 GMT+01:00 Achim Gratz:
> There is a build or packaging error somewhere with the 64bit version:
> the shutdown.exe delivered with the x86_64 package is in fact a 32bit
> executable that refuses to work in 64bit Cygwin.  Can you please correct
> and re-release the package?

Thanks for spotting.

There was a problem in the Makefile. I will re-release the package ASAP.

Regards,
Frank

--
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] Updated: shutdown 2.0-1

[Frank Fesevur]

Hi,

I've just updated the version of shutdown to v2.0-1 and it can be
found at a server near you.


FULL CHANGELOG (since shutdown-1.10-1)
==

* Added --install to install Windows Updates during shutdown/reboot.

  The InitiateShutdown() Windows API call is used for this. This function is
  only available from Windows 6.0 (aka Vista or Server 2008) or higher.
  To assure backwards compatibility with WinXP and Server 2003,
  InitiateShutdown() is loaded dynamically at runtime. Since Cygwin 2.6
  support for Windows XP and Server 2003 has been dropped, so this backward
  compatibility will be removed in a future release.

* Added --hybrid to shutdown in hybrid mode. Hybrid is the default shutdown
  method with shutting down with the UI of Windows 8.x and higher.

* The default shutdown messages will give more information on what is about
  to happen.

* User can supply his own shutdown message on the command line.

Enjoy!

Regards,
Frank

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

Updated: shutdown 2.0-1

[Frank Fesevur]

Hi,

I've just updated the version of shutdown to v2.0-1 and it can be
found at a server near you.


FULL CHANGELOG (since shutdown-1.10-1)
==

* Added --install to install Windows Updates during shutdown/reboot.

  The InitiateShutdown() Windows API call is used for this. This function is
  only available from Windows 6.0 (aka Vista or Server 2008) or higher.
  To assure backwards compatibility with WinXP and Server 2003,
  InitiateShutdown() is loaded dynamically at runtime. Since Cygwin 2.6
  support for Windows XP and Server 2003 has been dropped, so this backward
  compatibility will be removed in a future release.

* Added --hybrid to shutdown in hybrid mode. Hybrid is the default shutdown
  method with shutting down with the UI of Windows 8.x and higher.

* The default shutdown messages will give more information on what is about
  to happen.

* User can supply his own shutdown message on the command line.

Enjoy!

Regards,
Frank

SSH key for upload access

[Frank Fesevur]

Name: Frank Fesevur
Package: shutdown
 BEGIN SSH2 PUBLIC KEY 
B3NzaC1yc2EDAQABAAABAQCi5eVDKt69E7qYMI3wVuOjLnmn6GE6hCyDIchFud
WSHKEwh9k1OwQ4fPZWfsyKDupQgcn4h0/QoIEHNQBIoqCrqvLAMeIDa+/I5lsxdiK1D1ZR
y10zTgxfil6gA+1cjwFDLdqR1VM2V9HOCxMGKMFTwr+UY9ScFn0aCCZXC7QvnBf09IDXQz
5l2wCZfjRsj7N6IjFoWBmkF6WwUFAVNgZTAIwTK8ToOYsH452WEztlfvrlgyxM87atn2Ei
iI0YqaCncQhSTXvEdHbc8IgBPUJWuw8iT0/8VQImbGwW8MAfd6tiCsNcflCuUtrz+pFaAt
S0XBXLMazRPEPEYxLERmxB
 END SSH2 PUBLIC KEY 

Re: [ANNOUNCEMENT] Updated: OpenSSH-7.4p1-1

[Frank Fesevur]

2016-12-20 21:44 GMT+01:00 Corinna Vinschen:
>  * The next release of OpenSSH will remove support for running sshd(8)
>with privilege separation disabled.

Just noticed this.

Not sure what that means for Cygwin ssh servers.
I think I did the right thing when I installed ssh on my servers back
in the day, but any advise on how to see what choices I mad?

Regards,
Frank

--
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: Fwd: Re: DMARC - gmail.com or is it yahoo.com

[Frank Ch. Eigler]

Hi -

cygsimple wrote:

> See the description below of a problem that is occurring because of
> DMARC rules in place by yahoo.com.  Is there anything you can do for this?

cgf, any chance of updating our copy of ezmlm-toaster etc.?
Newer-than-2014 versions of ezmlm-idx seem to have some DMARC
capabilities.


- FChE

--
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: [ANNOUNCEMENT] vim 7.4.2367-1

[Frank Fesevur]

2016-09-20 18:42 GMT+02:00 Yaakov Selkowitz:
> The following packages have been uploaded to the Cygwin distribution:
>
> * vim-7.4.2367-1

Any specific reason why you didn't upgrade to the new 8.0 release?

Regards,
Frank

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

Suggestion for chere

[Frank Fesevur]

Hi Dave,

I have a suggestion for chere. It would be really nice if the Cygwin
icon/logo would be shown in front of the menu entry.

Right now I only have one "Bash Prompt Here" menu item, but other bash
implementations (MSYS2, Windows Git) also have a chere-like feature.
They add there icon in front of the menu item.

Take a look at this github issue:
https://github.com/Microsoft/BashOnWindows/issues/603
It shows two variants of "bash here" in the context menu.

Adding the icon is not that hard. See the .reg sample below. Just add
an extra entry named "Icon" with a full path to the Cygwin.ico file.

[HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin64_bash]
@=" Prompt Here"
"Icon"="C:\\Cygwin\\Cygwin.ico"

If you want to make this optional, the command line flag -I (capital
i) is the most logical available letter.

Regards,
Frank

--
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: Different representations of time in ls -l and date(1)

[Frank Farance]

On 2016-08-31 08:09, Markus Hoenicka wrote:

At 2016-08-31 13:41, Schwarz, Konrad was heard to say:

Sorry for the previous incomplete mail.

So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
uses 24 hour times.

$ ls -l rtos_benchmark.lst
-rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
$ date
Wed, Aug 31, 2016  1:39:35 PM
$ echo $LC_TIME

$ echo $LANG
en_US.UTF-8

Shouldn't they be using the same format?

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


date has a ton of options to format the output including the 12/24 h style, ,
see 'man date'.

regards,
Markus




Markus and Marco-

You have misunderstood the question.

Question Intended: Why are they different?
Incorrectly Interpreted: There are lots of options for "ls" and "date".

I have everything in 24-hour format, yet my LC_TIME and LANG are the same as 
Konrad.

Furthermore, I'd say that the default output of "date" should look like the 
Linux one, which is the way it has looked on UNIX for about 40 years:


Linux: Wed Aug 31 08:56:10 EDT 2016
Cygwin: Wed, Aug 31, 2016 08:54:49

In other words, on Cygwin: get rid of the commas, put back the timezone.

-FF

--
__
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: [ANNOUNCEMENT] Updated: mintty 2.4.3 and test release mintty 2.5.0

[Frank Fesevur]

2016-08-23 1:29 GMT+02:00 Thomas Wolff:
> I have also uploaded mintty 2.5.0 as a test release with the following
> change:
>
>   * Revise DPI handling (#470; #492, #487); always consider individual
> monitor DPI.
>
> Note that this release introduces a slightly incompatible change in mintty.
> The issue is that the interpretation of font size used to be suitable for
> traditional resolution monitors and did not consider higher-DPI monitors or
> the Windows monitor "zooming" feature which adjusts a virtual DPI.
> As a result, the handling of changed DPI (when moving the window to another
> monitor) introduced in 2.2.1 interfered with other aspects, the initial DPI
> was not considered, and a number of unpleasant side effects were
> occasionally observed.
>
> I intend to change DPI handling to be consistent with the respective monitor
> DPI (as optionally configured by "zooming factor"), and to comply with font
> size interpreation of other applications, e.g. notepad. In consequence the
> initial font size may be smaller (or larger) than before, depending on the
> actual monitor geometry and configuration. Nothing would change on a
> "standard" monitor configuration. To compensate, some people may have to
> change their font size configuration.

I was about to write a bug report that I encountered with a maximized
mintty on a 125% secondary screen. When I minimized it to the taskbar
it would restore to my primary screen. But that problem is fixed now,
so for me 2.5.0 solves that problem even before reporting it. The
draft mail is thrown away ;-)

Thanks for the fix!

Frank

--
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: Up for adoption: ctags and expat

[Frank Fesevur]

2016-08-12 12:19 GMT+02:00 Corinna Vinschen:
> On Aug 12 11:01, Frank Fesevur wrote:
>> Universal ctags is the continuation of exuberant ctags. We have tried
>> to convince Darren Hiebert (the original author of exuberant) to team
>> up so we could keep the name. But that didn't work out, so we had to
>> fork and came up with the name universal.
>
> Pity.

Absolutely.

>> I would say, make the switch to universal. I am willing to maintain
>> that package. Question is how to update a package without official
>> releases. And it hasn't been included in any major distro AFAIK.
>
> You could start with a test build and set the version numbers in the
> setup.hint file explicitely.  If it works out fine, you only have to
> keep up with the prev/curr markers as long as "prev" is the exuberant
> package.  Question is, *are* there any version numbers yet?  If not,
> you could use git commit IDs for the time being.

There is no version number yet. The expectation is it will become 6.0
so something like 5.9-date-shorthash could a temporary version number
for a test release. The compile date and hash are shown when "ctags
--version" is invoked.

I just tried and the basic compilation of the current master branch works.

Regards,
Frank

BTW. Did you know that a coworker of you is the lead developer of
universal ctags? https://github.com/masatake

Re: chere mintty window position

[Frank Fesevur]

2016-08-12 6:04 GMT+02:00 Brent:
> Thomas Wolff wrote:
>>How about mintty -w max or -w full instead?
>
> Thanks, I am going to try that tomorrow.

I'm not use, but I think Thomas meant that as a possible yet to be
written command line option.

Regards,
Frank

--
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: Up for adoption: ctags and expat

[Frank Fesevur]

2016-08-12 10:11 GMT+02:00 Corinna Vinschen:
> Given the obvious lack of upstream development, did anybody try
> to replace exuberant ctags with universal ctags?
>
>   https://ctags.io/
>
> I noticed that our co-maintainer Frank Fesevur is involved in this
> project.  Frank, any insight?

I have been active in the development of universal ctags, but at the
moment not too much.

Universal ctags is the continuation of exuberant ctags. We have tried
to convince Darren Hiebert (the original author of exuberant) to team
up so we could keep the name. But that didn't work out, so we had to
fork and came up with the name universal.

My main reason to help out was to make sure it kept working on native
Windows. I use ctags for a Notepad++ plugin I wrote.

I have successfully compile universal ctags for cygwin a while ago and
it worked. Not sure how it is at the moment. There have been some
changes in the build files so not sure if cygwin still works. Pull
request are always reviewed.

Among many other improvements, universal ctags has more and better
parsers. You can add your own parser with an external program or with
regexs. You can write the output as JSON.

There hasn't been any official release. ATM there is no-one working on
that. Making all the docs up-to-date with all the development that has
been going on is the biggest task.

I would say, make the switch to universal. I am willing to maintain
that package. Question is how to update a package without official
releases. And it hasn't been included in any major distro AFAIK.

Regards,
Frank

Re: clock skew detected in archive member

[Frank Farance]

On 2016-07-19 15:44, Schwarz, Konrad wrote:

Hello,

I am building a project in Cygwin using a GCC/binutils cross-compiler hosted on 
Windows.
I.e., make and other utilities are from Cygwin;
gcc, ld, ar, etc. are from the cross-compiler toolchain which was compiled 
natively
for Windows.

I consistently see
make[1]: Warning: File 'libmylib.a(myfile.o)' has modification time 
3516 s in the future
make[1]: warning:  Clock skew detected.  Your build may be incomplete.

(The exact time varies somewhat).

The build is indeed incomplete.

I am using the lib(member): form of rule in the Makefile, so
make uses the modification time of the member in the archive
to see if it needs updating.

As the time is close to an hour and since I am one hour east of GMT,
this might be related to a time-zone problem.

If anyone has run across this problem and has some hints for me,
I would be most grateful.

Best Regards

Konrad Schwarz


Konrad-

Here is my experience operating in a mixed environment.  There seem to be 
several routes to getting timestamps on files ... Windows (via Windows explorer) 
can produce different results than Cygwin, even on the same NTFS volume.  Now if 
you were able to roll the clock back a couple months to Winter time, you might 
have fewer problems.  Not to mention, if you're using remotely mounted drives, 
there can be some jitter too that causes Makefile problems -- these problems 
have been around for almost three decades on pure *nix systems, no Windows OS.


Now add in archives (whose time should be right because it is in UTC), but the 
file itself (which was copied into the archive) might have the wrong time 
(stupid TZ issues from the file's metadata in the filesystem, not the archive 
which merely copies the filesystem metadata).


The easiest way to see this problem is with files that are "self-timestamped", 
such as JPEG EXIF metadata in a photo file taken in December (Northern 
Hemisphere winter) and viewed in Summer time (or vice versa).  You'll see hour 
differences, which of course are not true.


The solution?  Essentially, (1) you need to build on local filesystems (applies 
to UNIX and Windows OS), (2) you need to have a single route for determining 
timestamp/TZ data on files (probably means you can't mix Windows and Cygwin), 
(3) building the files with "TZ=UTC0" (or equivalent) should minimize timezone 
and summer time issues.


I'm sure there is a more detailed explanation in the inner guts of cygwin and 
Windows OS, but I've lost too much time over the years trying to make sense out 
of it and reconciling what has been written on the web that, in fact, does not 
describe what is happening on my machines.  The timezones/summer time has been 
broken on DOS and Windows since Day 1, and they broke it again, and they broke 
it again.


-FF

--
______
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Frank Brill]

I rebooted my PC in Safe Mode and everything works fine on the same PC with the 
same cygwin64 installation.  CMake is OK in Safe Mode.  

Some other processes that run during regular boot must be interfering with 
CMake.  Definitely BLODA.  I never even heard that term before yesterday, and 
look at me now.

If I ever figure out specifically what is interfering I'll post it.


--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Frank Brill]

The attached zip file contains the results when I create a directory called 
cmaketest64, 
put the two files from my previous post (CMakeLists.txt and tutorial.cxx) in 
it, and type "cmake ."

I had to change the file extension from .zip to .z__ and remove two .exe files 
to get past the spam filters:

cmaketest64/CMakeFiles/3.3.2/CompilerIdC/a.exe
cmaketest64/CMakeFiles/3.3.2/CompilerIdCXX/a.exe



cmaketest64.z__
Description: cmaketest64.z__
--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Frank Brill]

Tony Kelman writes:
> I'm at a conference this week so really busy, but it sounds like I may
> need to update cmake to the latest version (which is overdue anyway)
> if something in the latest gcc is unhappy. Can you provide full
> reproduction steps, a source repo or tarball to download? Also looking
> into (and posting) the full content of the cmake error/output log
> files might provide more information about what the problem is

I made the world's smallest example, taken from the CMake tutorial.  
There's a CMakeLists.txt that contains this:

cmake_minimum_required (VERSION 2.6)
project (Tutorial)
add_executable(Tutorial tutorial.cxx)

and a tutorial.cxx that contains this:

// A simple program that computes the square root of a number
#include 
#include 
#include 
int main (int argc, char *argv[])
{
  if (argc < 2)
{
fprintf(stdout,"Usage: %s number\n",argv[0]);
return 1;
}
  double inputValue = atof(argv[1]);
  double outputValue = sqrt(inputValue);
  fprintf(stdout,"The square root of %g is %g\n",
  inputValue, outputValue);
  return 0;
}

Just create the two files above and do: 

$ cmake .
$ make
$ ./Tutorial 2

On 32-bit Cygwin, it all works nicely as expected.  But on my fresh 64-bit 
installation, I get the " not able to compile a simple test program" message.

I think Hans-Bernhard's theory that there's some other app interfering is
probably correct, and it probably has something to do with my company's 
security software.  

I will post more information in subsequent posts that hopefully stay under
the "spam score threshold". 


--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Frank Brill]

Hans-Bernhard Bröker writes:
> One possibly important difference is that you keep your source tree in the 
> Windows user profile directory; I never subscribed to that idea.

I've put the source tree in a number of places with the same result.  I'll try 
again at any location you suggest.

>  What this brings to mind is that maybe an antivirus program or other BLODA 
> is getting in the way here.

This would explain why I'm having the same bad behavior on multiple PC's at 
work--they all have the same BLODA.  But it's strange that 32-bit works and 
64-bit doesn't, and that an older version of 64-bit Cygwin worked.  I will try 
from my home PC to see what happens.  

I am also trying to send a message with a more complete package of the errors, 
but so far the mail server on one end or the other has rejected my attempts.  
Will keep trying.

   -- Frank


--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Frank Brill]

Marco Atzeri writes:

> what is the content of
>   cmake_link_script
>   CMakeFiles/cmTC_5d15a.dir/link.txt

None of these files exists after the failed cmake exits.  The directory 
./CMakeFiles/CMakeTmp is created, but it's empty.  The entire directory 
structure that is remaining after executing "cmake ." is attached to my 
previous post as cmaketest64.zip.

   -- Frank


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

Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Frank Brill]

I am having trouble building an open source project using cmake under Cygwin64 
with the latest tools (setup-x86_64.exe version 2.874).  

I was able to successfully build the project with 32-bit Cygwin with the latest 
tools:  gcc 5.4.0, gnu make 4.2.1, and cmake 3.3.2.

I was also able to successfully build the project under Cygwin64 using older 
tools: gcc 4.9.3, gnu make 4.1, and cmake 3.3.2.

But when I updated my Cygwin64 installation to the latest tools (gcc 5.4.0, gnu 
make 4.2.1, cmake 3.3.2) the build failed with the error message below.  I 
tried wiping my Cygwin64 installation and reinstalling from scratch but got the 
same result.  I thought it might be a PATH problem so I set my path the 
"/usr/bin" and still got the same result.  The CMakeFiles/CMakeTmp directory 
mentioned in the error message below was created, but there's nothing in it.

Can someone provide some advice that can help me fix my Cygwin64 installation 
so that cmake works properly?

   -- Frank

$ cmake -DOPENVX_INCLUDES=$OPENVX_DIR/include 
-DOPENVX_LIBRARIES=$OPENVX_DIR/out/CYGWIN/x86_64/release/libopenvx.dll.a\;$OPENVX_DIR/out/CYGWIN/x86_64/release/libvxu.dll.a
 ../conformance_tests/
-- The C compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-3.3.2/Modules/CMakeTestCCompiler.cmake:61 
(message):
  The C compiler "/usr/bin/cc" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: 
/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp



  Run Build Command:"/usr/bin/make.exe" "cmTC_5d15a/fast"

  /usr/bin/make -f CMakeFiles/cmTC_5d15a.dir/build.make
  CMakeFiles/cmTC_5d15a.dir/build

  make[1]: Entering directory
  
'/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp'


  Building C object CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o

  /usr/bin/cc -o CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o -c
  
/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp/testCCompiler.c


  Linking C executable cmTC_5d15a.exe

  /usr/bin/cmake.exe -E cmake_link_script CMakeFiles/cmTC_5d15a.dir/link.txt
  --verbose=1

  /usr/bin/cc -Wl,--enable-auto-import
  CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o -o cmTC_5d15a.exe
  -Wl,--out-implib,libcmTC_5d15a.dll.a
  -Wl,--major-image-version,0,--minor-image-version,0

  make[1]: Leaving directory
  
'/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp'


  Error running link command: No such file or directory

  make[1]: *** [CMakeFiles/cmTC_5d15a.dir/build.make:98: cmTC_5d15a.exe]
  Error 2

  make: *** [Makefile:126: cmTC_5d15a/fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:34 (project)


-- Configuring incomplete, errors occurred!
See also 
"/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeOutput.log".
See also 
"/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeError.log".





cygcheck.out
Description: cygcheck.out
--
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

GitHub shutdown repo

[Frank Fesevur]

Hi,

I recently transferred my shutdown repo from my personal github
acoount to the cygwin organization.

Could anybody with the right permissions rename the repo to just "shutdown"?

Regards,
Frank

--
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: ctrl-c doesn't reliably kill ping

[Frank Farance]

Folks-

Thank you for the thoughtful observations, responses, and suggestions, which I 
will summarize:


- Suggestion #1: Try different DNS settings not using Verizon.
- Suggestion #2: Try different Verizon configuration.
- Suggestion #3: Try Windows version of ping.
- Observation #4: This shouldn't work unless I am administrator (FYI: I've 
configured the cygwin terminal to run as administrator).
- Question #5: Am I running the windows ping?  Answer: Nope, I did "type ping", 
which returned "/usr/bin/ping".


Regarding Verizon, and possibly different settings, my point was not to identify 
flaws in Verizon, I just wanted to give you background on the problem - and I 
believe people understand its nature.  I am well aware of well-known DNS 
servers, such as 8.8.8.8 and 8.8.4.4 -- I am Old School, so I still occasionally 
use the UUNET DNS caches 198.6.1.? to test stuff. :-)


Regarding incompatible ISPs, I believe the program should be robust enough to 
succeed, robust enough to fail, but it shouldn't hang and become non-interruptable.


So from a POSIX compatibility and operating system kernel perspective, I am 
surprised that it is possible to write an application program that gets into an 
non-interruptable state.  In traditional UNIX kernels, it was possible to get 
stuck in a *hard* wait (like local hard drive access), but I don't understand 
how this is possible with ping or any other network application.


Perhaps I don't understand the cygwin signal mechanism and someone can point me 
in the right direction for ping.  Perhaps someone can explain how ping can get 
into this state.


Anyway, as we'd say in standardizing the C programming language, this behavior 
is a "surprise" ... and we should look to eliminate "surprises".


Again, thank you in advance for your help.

-FF


--
______
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

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

ctrl-c doesn't reliably kill ping

[Frank Farance]

I have been having this problem with "ping".  If I "ping" a location that 
doesn't exist, then "ping" just hangs and cannot be killed via "kill -KILL [pid]".


A little digression, so you understand the background ... The workstation I am 
doing this from is connected to a Verizon router to their FIOS network.  Now the 
reason I mention this is that the router's DNS (via DHCP to my workstation) is 
192.168.1.1, which I presume is forwarded from the router upstream to Verizon's 
DNS caches.  So if I type the URL http://something.that.doesnt.exist in my 
browser, rather than getting a Hostname Not Found error (at the name resolution 
level), it actually loads up a page saying "something.that.doesnt.exist" isn't 
found and then I have a Yahoo set of search results on things matching the 
broken hostname.


So all of this is normal ISP stuff: they actually resolve unknown addresses to 
their own website (which is 90.242.140.21).


Ok, ending the digression 

Back to the problem, so when I type

$ ping some.unknown.host

according to "ping", the hostname resolves to 90.242.140.21 (as per the 
explanation above), but I cannot kill "ping".  I tried "ping" with a limited 
packet size and count so, in theory, "ping" would die on its own after 10 
packets, such as:


$ ping some.unknown.host 50 10

but it still hangs rather than timing out.  If I ping to some actual IP address 
that is unresponsive (route-able to the last subnet, but dies on the floor at 
the end), then I can kill via ctrl-c.  My only solution to the hanging "ping" is 
to kill the terminal window.


Any suggestions on:

- Why "ping" behaves this way?
- How to avoid this problem?

Thanks, in advance.

-FF

--
__
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

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

Ruby gem install falis

[Frank Fesevur]

Hi,

I am unable to install a gem:

# gem install gollum
ERROR:  Loading command: install (LoadError)
No such process - /usr/lib/ruby/2.2.0/openssl.so
ERROR:  While executing gem ... (NoMethodError)
undefined method `invoke_with_build_args' for nil:NilClass

When I try "gem update" the same error occurs.

>From what I read on various sites on the internet is that Ruby needs
to be rebuild with the latest openssl. A new version of the openssl
package was released recently.

I have very little experience with Ruby. Just using some software that
need to be installed as gems. Is rebuilding something I can do myself
or does the Ruby packages needs to be rebuild?

Regards,
Frank

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

[Frank Esposito]

Thanks -- that show me what dll was missing --

On Wed, Jan 6, 2016 at 7:54 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:
> On 06/01/2016 05:08, Frank Esposito wrote:
>>
>> I am having an  problem starting emacs within cygwin/bash --
>>
>> I am getting this message
>>
>> C:/CYGWIN/bin/emacs-X11.exe: error while loading shared libraries: ?:
>> cannot open shared object file: No such file or directory
>>
>> Is there a way I can debug the startup of emacs to see what is missing?
>> env vars?
>>
>> Thanks
>
>
> this should produce a more clear error message
>
>   strace -o emacs-X11.strace /usr/bin/emacs-X11.exe
>
>
>
>
> --
> 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
>



-- 
Frank Esposito

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

[Frank Esposito]

Hello --

Thanks for the help -- I don't recall doing anything with cygport --
the one item that can be an issue is that I had cygwin on this
computer when the os was XP then I update the OS to Vista -- and did
not reinstall cygwin -- just did updates on top of the existing
install -- here is the output file requested

On Wed, Jan 6, 2016 at 1:40 PM, Marco Atzeri <marco.atz...@gmail.com> wrote:
>
>
> On 06/01/2016 17:41, Frank Esposito wrote:
>>
>> Hello --
>>
>> Thanks for the info on the strace command
>>
>> what I found is that at first, emacs was trying to load
>>
>> cyghogweed-2.dll
>
>
> it belongs to libhogweed2-2.7-2
>
>>
>> but what was in the bin directory was
>>
>> cyghogweed-2-2.dll
>
>
> this is not part of standard cygwin
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=cyghogweed-2-2.dll=x86
>
> have you mixed up an upgrade with cygport ?
>
>> I tried to rename this, but that did not work, so I copied
>> cyghogweed-2.dll from another install of cygwin
>>
>> then it stoped again looking for
>>
>> cygnettle-4.dll
>
>
> libnettle4-2.7-2
>
>>
>> but
>>
>> cygnettle-4-4.dll
>
>
> as before
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=cygnettle-4-4.dll=x86_64
>
>>
>> was in the bin directory -- I just copied
>> cygnettle-4.dll to the bin directory and  now emacs stated --
>>
>> what would be the best way fix this? are these dll's part of the emacs
>> package?
>>
>> thanks
>>
>> fpe
>
>
>
>>> Problem reports:   http://cygwin.com/problems.html
>
>
> Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment
> in your report. Please do not compress or otherwise encode the output. Just
> attach it as a straight text file so that it can be easily viewed.
>
>
>
> --
> 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
>



-- 
Frank Esposito


cygcheck.out
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: emacs

[Frank Esposito]

Hello --

Thanks for the info on the strace command

what I found is that at first, emacs was trying to load

cyghogweed-2.dll

but what was in the bin directory was

cyghogweed-2-2.dll

I tried to rename this, but that did not work, so I copied
cyghogweed-2.dll from another install of cygwin

then it stoped again looking for

cygnettle-4.dll

but

cygnettle-4-4.dll

was in the bin directory -- I just copied
cygnettle-4.dll to the bin directory and  now emacs stated --

what would be the best way fix this? are these dll's part of the emacs package?

thanks

fpe

On Wed, Jan 6, 2016 at 7:54 AM, Marco Atzeri <marco.atz...@gmail.com> wrote:
> On 06/01/2016 05:08, Frank Esposito wrote:
>>
>> I am having an  problem starting emacs within cygwin/bash --
>>
>> I am getting this message
>>
>> C:/CYGWIN/bin/emacs-X11.exe: error while loading shared libraries: ?:
>> cannot open shared object file: No such file or directory
>>
>> Is there a way I can debug the startup of emacs to see what is missing?
>> env vars?
>>
>> Thanks
>
>
> this should produce a more clear error message
>
>   strace -o emacs-X11.strace /usr/bin/emacs-X11.exe
>
>
>
>
> --
> 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
>



-- 
Frank Esposito

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

emacs

[Frank Esposito]

I am having an  problem starting emacs within cygwin/bash -- 

I am getting this message 

C:/CYGWIN/bin/emacs-X11.exe: error while loading shared libraries: ?: cannot 
open shared object file: No such file or directory

Is there a way I can debug the startup of emacs to see what is missing? env 
vars? 

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

emacs

[Frank Esposito]

I am having an  problem starting emacs within cygwin/bash --

I am getting this message

C:/CYGWIN/bin/emacs-X11.exe: error while loading shared libraries: ?:
cannot open shared object file: No such file or directory

Is there a way I can debug the startup of emacs to see what is
missing? env vars?

Thanks

fpe

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

Missing volumes in output from df -h

[Frank Redeker]

Hello list,

I just noticed 2 missing volumes when executing df -h from inside 
[CYGWIN_NT-6.1 Mimir
2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin]


$ mount
D:/Program_Files_64/cygwin64/bin on /usr/bin type ntfs (binary,auto)
D:/Program_Files_64/cygwin64/lib on /usr/lib type ntfs (binary,auto)
D:/Program_Files_64/cygwin64 on / type ntfs (binary,auto)
B: on /cygdrive/b type ntfs (binary,posix=0,user,noumount,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto)
M: on /cygdrive/m type ntfs (binary,posix=0,user,noumount,auto)
N: on /cygdrive/n type ntfs (binary,posix=0,user,noumount,auto)
O: on /cygdrive/o type smbfs (binary,posix=0,user,noumount,auto)
P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)
T: on /cygdrive/t type ntfs (binary,posix=0,user,noumount,auto)
W: on /cygdrive/w type smbfs (binary,posix=0,user,noumount,auto)


The volumes B: and T: are no real drives but created with subst.

$ subst
B:\: => F:\Projects
T:\: => F:\T


$ df -h
FilesystemSize  Used Avail Use% Mounted on
D:/Program_Files_64/cygwin64  112G   42G   70G  38% /
B:469G   84G  386G  18% /cygdrive/b
C:115G   87G   29G  76% /cygdrive/c
E:463G  215G  249G  47% /cygdrive/e
M:233G   72G  161G  31% /cygdrive/m
N:230G  143G   87G  63% /cygdrive/n
O:856G  751G  105G  88% /cygdrive/o
P:285G  181G  105G  64% /cygdrive/p
W:209G  179G   30G  86% /cygdrive/w

$ df -h /cygdrive/f
Filesystem  Size  Used Avail Use% Mounted on
F:  469G   84G  386G  18% /cygdrive/f


When executing df from inside my old [CYGWIN_NT-6.1-WOW64 Mimir
1.7.33-2(0.280/5/3) 2014-11-13 15:45 i686 Cygwin] the result is somewhat
different. Here drive B: and F: are missing but T: is present.


$ df -h
Filesystem  Size  Used Avail Use% Mounted on
C:  115G   87G   29G  76% /cygdrive/c
T:  469G   84G  386G  18% /cygdrive/t
D:  112G   42G   70G  38% /cygdrive/d
E:  463G  215G  249G  47% /cygdrive/e
M:  233G   72G  161G  31% /cygdrive/m
N:  230G  143G   87G  63% /cygdrive/n
O:  856G  751G  105G  88% /cygdrive/o
P:  285G  181G  105G  64% /cygdrive/p
W:  209G  179G   30G  86% /cygdrive/w


Frank



I tried to report this from my registered mailing list account f.redeker (at) 
razorcat.de. But that mail was rejected because of spam classification. Maybe 
this happend because of the attached cygcheck and strace output.

If the cygcheck and strace is needed to find out what going on I will try send 
it again.



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

Life time of AST elements.

[Frank Redeker]

Hello all,

I'm writing a tool to analyze the call hierarchy of functions (methods)
using ClangTool.

My idea is to collect the TranslationUnitDecls given to my own
ASTCosumer's HandleTranslationUnit method and traverse them later when
ClangTool.run() has finished.

But it seems that the AST nodes are no longer valid after
ClangTool.run() has returned. (e.g. If I call getQualifiedNameAsString()
on a FunctionDecl object retrieved from the TranslationUnitDecl, I get
`Assertion failed: DC && "This decl is not contained in a translation
unit!"`)

So I wonder if there is any trick to extend the life time for the AST or
should I use ClangTool.buildAST() rather then ClangTool.run() to get the
ASTs ?


Frank

--
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: Life time of AST elements.

[Frank Redeker]

Am 12.10.2015 um 14:37 schrieb Frank Redeker:
> Hello all,
> 
> I'm writing a tool to analyze the call hierarchy of functions (methods)
> using ClangTool.
> 
> My idea is to collect the TranslationUnitDecls given to my own
> ASTCosumer's HandleTranslationUnit method and traverse them later when
> ClangTool.run() has finished.
> 
> But it seems that the AST nodes are no longer valid after
> ClangTool.run() has returned. (e.g. If I call getQualifiedNameAsString()
> on a FunctionDecl object retrieved from the TranslationUnitDecl, I get
> `Assertion failed: DC && "This decl is not contained in a translation
> unit!"`)
> 
> So I wonder if there is any trick to extend the life time for the AST or
> should I use ClangTool.buildAST() rather then ClangTool.run() to get the
> ASTs ?
> 
Sorry,

wrong mailing list!


Frank


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

ssh with password allows commands that fail with ssh via key

[Blando, Frank (Helion Managed Engineering)]

I suspect this is already answered somewhere, but my googling has not brought 
up an answer.

Environment:
CygWin with OpenSSH 6.6.1p1-3 on Windows 2012 R2. Using the domain 
administrator account as the target on Windows.

Issue:
When I ssh into Windows from Linux, if I use a password, "powershell -command 
get-cluster" works. If I use key (store in .ssh/authorized_keys), "powershell 
-command get-cluster" returns access denied. Simpler commands do not appear to 
make a distinction and work equally well with password or keys.

--
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: ssh with password allows commands that fail with ssh via key

[Blando, Frank (Helion Managed Engineering)]

Thanks you for the pointer. I hope I read this correctly (It is kind of 
overwhelming), and unfortunately, that does not appear to be it.
1 - Unlike the mentioned description, access to network share works fine either 
way (Example command that works either way "powershell -command get-childitem 
\\server\share") - I have enabled CredSSP and I this might be why.
2 - Using passwd -R to register the password did not make the problem go away 
(In the windows tradition I restarted the service and killed all sessions)

Frank Blando
Your English beats my non-existent Russian!
-Original Message-
From: Andrey Repin [mailto:anrdae...@yandex.ru] 
Sent: Thursday, October 1, 2015 5:27 PM
To: Blando, Frank (Helion Managed Engineering) <frank.bla...@hpe.com>; 
cygwin@cygwin.com
Subject: Re: ssh with password allows commands that fail with ssh via key

Greetings, Blando, Frank (Helion Managed Engineering)!

> I suspect this is already answered somewhere, but my googling has not brought 
> up an answer.

> Environment:
> CygWin with OpenSSH 6.6.1p1-3 on Windows 2012 R2. Using the domain 
> administrator account as the target on Windows.

> Issue:
> When I ssh into Windows from Linux, if I use a password, "powershell 
> -command get-cluster" works. If I use key (store in 
> .ssh/authorized_keys), "powershell -command get-cluster" returns 
> access denied. Simpler commands do not appear to make a distinction and work 
> equally well with password or keys.

Please read the documentation. It is explicitly explained there in great detail.
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview


--
With best regards,
Andrey Repin
Friday, October 2, 2015 02:24:20

Sorry for my terrible english...


--
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: [ANNOUNCEMENT] Early Deprecation Notice: Windows XP and Server 2003 support

[Frank Fesevur]

2015-08-26 15:42 GMT+02:00 Andrey Repin:
 And since Vista+ doesn't have support for 16-bit subsystem, I need XP VM to
 compile my projects.

AFAIK the 16-bit subsystem has nothing to do with XP vs Vista+. It has
to do with 32-bit OS vs 64-bit OS. Have you tried a 32 bit Win7 (or
maybe even a 32-bit Win10)?

Regards,
Frank

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

cygwin memory leak

[Frank Morauf]

Running the following lines let windows physical memory grow until no
more left (task-manager: physical memory). The taken memory is never
freed until os restart. This happens also while compiling huge
projects. Tested on three different Windows 7 x64 machines with actual
cygwin 2.x (32 and 64 bit).

#!/bin/sh
while (( 1 )); do
/bin/true
done

cygcheck.out
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: mintty project

[Frank Fesevur]

2015-06-04 8:29 GMT+02:00 Thomas Wolff:
 I have acquired that account meanwhile but apparently it cannot be turned
 into an org. account, rather it would need to be attached to a separate org.
 account (weird policy).

Does this help?
https://help.github.com/articles/converting-a-user-into-an-organization/

 Actually there is also an orphaned github account called cygwin which
 could be claimed by a cygwin maintainer (Corinna?), maybe as an option to
 host cygwin packages.

Suggested that as well in my previous mail.

 Apart from that, I am still hesitating to go with github.com. What do people
 think about gitlab.com instead? It makes a more serious impression and has
 some more professional features. Or maybe codebase.com?

I cannot tell you anything about the other sites you mention. But I
know that the community is at github at the moment. Many examples
exist. See the graph Tony posted. I experienced it myself as well. Or
see the Our choice of using GitHub section on this blogpost of
Microsoft 
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx

I am sure the community will build around mintty, once people start to
noticed the move. And for that ask Andy to put a link to the new repo
on the Google Code page.

Regards,
Frank

--
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: mintty project

[Frank Fesevur]

2015-06-01 10:36 GMT+02:00 Corinna Vinschen:
 On May 31 23:15, Thomas Wolff wrote:
 As a contributor to mintty, some sent me a notice discussing the move to
 github 
 (http://www.reddit.com/r/cygwin/comments/37vgwi/what_happened_to_minttys_maintainer_andy_kopp/)
 and now there is already a github fork of mintty
 (https://github.com/nowox/mintty/tree/master/src).

I see that nowox only imported the repo from Google Code very
recently, most likely by simply pressing the Export to GitHub button
on Google Code. And didn't make much real changes to his repo so
far.

 I'd like to discuss what you (cygwin maintainers and others) think of this
 move, whether it's good for mintty to be hosted on github. Personally I feel
 that a platform like sourceforge provides a more professional project
 environment which would provide more confidence in stable project
 development.
 What do you think?

I agree with Tony. Although I am still using the SF alias as one of my
email addresses I think at this moment GitHub has the most active
community. If you want to have a greater change on others contributing
I would really go for GitHub. Seen it happen so many times already,
move a project to GH and the PRs start coming.

 It's not so much the hosting service providing the upstream repository
 which concerns me, it's the lack of development, the lack of a responsive
 maintainer, and the lack of a new, stable mintty package.  You're in for
 one of the newly created pink plush hippos if you're going to take over
 mintty maintainership ;)

 Having said that, github is ok.

Would it be useful for cygwin to have its own place on GitHub? This
could be the place to host the mintty sources and maybe other things
as well.

There is a user named cygwin on github, but it appear very inactive.
https://github.com/cygwin
GitHub has a policy for that:
https://help.github.com/articles/name-squatting-policy/

So if interested, maybe Corinna or Yaakov (being our project leaders)
could ask GitHub to hand that account to them. And after that turn it
into an organization where projects like this can be hosted. This way
the project doesn't depend on one person to have full access when
needed to these kind of repos.
Just an idea.

Regards,
Frank

--
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: multitail segfaults

[Frank Fesevur]

2015-04-23 11:04 GMT+02:00 Dr. Volker Zell:
  Subject: Re: multitail segfaults
  I also have this problem when I use multitail.

  $ multitail --version
   --*- multitail 6.3 (C) 2003-2014 by folk...@vanheusden.com -*--

  The following problem occured:
  -
  [1]10832 segmentation fault (core dumped)  multitail --version


 For me it works on 32bit cygwin, but on 64bit I get an error:

  xclip binary 'xclip' does not extist

 and in fact 32bit has /usr/bin/xclip installed but in 64bit it's missing

Manually installing xclip solves the crash for me. So while you are on
it, could you please update the dependencies of the multitail package?

Regards,
Frank

--
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: [ANNOUNCEMENT] Updated: vim-7.4.692-1

[Frank Fesevur]

2015-04-13 17:19 GMT+02:00 Yaakov Selkowitz:
 The following packages have been updated in the Cygwin distribution:

 * vim-7.4.692-1
 * vim-common-7.4.692-1
 * vim-minimal-7.4.692-1
 * xxd-7.4.692-1
 * gvim-7.4.692-1

 Vim is an advanced text editor that seeks to provide the power of the
 de-facto Unix editor 'Vi', with a more complete feature set and a choice
 of terminal and GTK+ interfaces.

 This is an update to the latest upstream patchset.

Is it by design that vim now requires tcsh?

tcsh(6.18.01-6)
An enhanced version of csh, the C shell
Required by: vim-common

Regards,
Frank

--
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: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]

[Frank Fesevur]

2015-04-10 22:38 GMT+02:00 Andrew DeFaria:
 $ man 5 crontab

 See @reboot

 Never used it but I assume it will run after cron service is started.

 I haven't used it either, but I saw it there. Makes you wonder what would
 happen if you simply restarted the service or stopped it and then started it
 again.

Have cron installed on my laptop so I just tested. And yes, that is
how @reboot works on Cygwin. It runs the job right after the cron
daemon is started, regardless how many times you restart the service.

On Linux it seems to detect that the system really was rebooted.

Regards,
Frank

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

multitail segfaults

[Frank Fesevur]

Hi,

I'm experiencing a problem with multitail. It always gives a segmentation fault.

$ multitail --version
 --*- multitail 6.3 (C) 2003-2014 by folk...@vanheusden.com -*--

The following problem occured:
-
Segmentation fault (core dumped)

I see this behavior on all my installations. cygcheck -srv doesn't
show anything special. After downgrading to the previous version
(5.2.12) it works again.

Anyone else seeing the same problem?

Regards,
Frank

--
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: Cygwin Git thinks files are changed when they aren't

[Frank Fesevur]

2015-03-24 21:42 GMT+01:00 Chloe:
 Cygwin Git always thinks files are changed even when they aren't. After a
 commit with a Windows Git, Cygwin Git shows files as modified.
 [snip]
 $ git diff .project
 diff --git a/.project b/.project
 old mode 100644
 new mode 100755

Apart from the file mode already mentioned, don't forget that Windows
based git uses CRLF as line endings where Cygwin git uses LF as
default line ending (like a Linux based git). Could lead to modified
files as well. I avoid mixed the two as much as possible. I use Cygwin
git to do all the real operations and use TortoiseGit (together with
Windows based git) just to see in the Windows Explorer what is
happening in my directories. There is a tweak introduced in the most
recent TortoiseGit to use Cygwin git, but have tried that yet.

Regards,
Frank

--
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: rsync still broken

[Frank Fesevur]

2015-03-12 21:34 GMT+01:00 Linda Walsh:
 It sounds like the group you are in on cygwin doesn't exist or you are not
 in it on your target machine.

 what group are you in on the windows machine?
 if you type 'id', the 2nd number should be your primary gid.

 uid=1234(Bliss\law) gid=123(lawgroup) groups=123(lawgroup)...

The first gid of the user running the rsyncd service is 512, but...

 Then the question is, does your groupname
 exist on the server you are transferring it to?  (or if you are using
 '--numeric-ids, is your
 group# (gid) the same on the server you are transferring files to?

... I use --numeric-ids and I have these two lines in the rsyncd.conf
uid = 0
gid = 0

If I understand it correctly now rsync sends all files with uid=0 and
gid=0. And obviously those uid and gid exist on the Linux machine.

 If not, are you using the --usermap and/or
 --groupmap options to map your Windows ID's to
 your server's ID's?

No, I don't use that.

 Maybe you have already verified this, but usually
 when I get errors in a transfer, it's because the UID's
 or user/groupnames on my windows machine don't always match
 what is on my server -- they mostly do, but I do see
 errors occasionally in it trying to set things.

I thought uid=0 and gid=0 would solve that.

 You can also try the --fake-super option -- that
 might fake the id's enough for it to work...

There is a fake super = yes in the rsyncd.conf and the --fake-super
option is added on the Linux server.

But the thing that surpises me is that in 3.0.9 is just worked.

Regards,
Frank

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

rsync still broken

[Frank Fesevur]

Hi Jari,

It looks like rsync is still broken. When you released 3.1.0 it had an
upstream bug that made it extremely slow on cygwin. Other then that it
also had another problem that I reported here:
https://www.cygwin.com/ml/cygwin/2014-08/msg00440.html

Yaakov made 3.1.0 test and we all automatically reverted to 3.0.9.

Recently 3.1.1 was released leaving the broken test version 3.1.0 as
previous. I didn't update my servers yet, The day before yesterday I
did, so I went from 3.0.9 to 3.1.1.

And yesterday I saw that my backup *completely* failed because of these errors:
@ERROR: setgid failed
rsync error: error starting client-server protocol (code 5) at
main.c(1653) [Receiver=3.1.0]
ERROR: /usr/bin/rsync returned 5 while processing
rsync://192.168.200.208/backup-d/DataShares/
@ERROR: setgid failed
rsync error: error starting client-server protocol (code 5) at
main.c(1653) [Receiver=3.1.0]
ERROR: /usr/bin/rsync returned 5 while processing
rsync://192.168.200.208/backup-d/DataGit/
@ERROR: setgid failed

Very similar error as I reported for 3.1.0.

FYI, I run the cygwin based rsync daemon on my Windows servers and
have a Ubuntu server that backups the data with rsnapshot (which
utilizes rsync to do the transfers). The errors above are shown on the
Ubuntu server.

Luckily I still had a 3.0.9 executable on one machine and I've put
that exe on all the updated servers to make sure the backup worked
again last night. So those systems new think they have 3.1.1 but the
actually have the exe of good old properly working 3.0.9

Note that 3.0.9 is not available on the mirrors anymore. I hope that
it can be restored on the mirrors and made current again for the time
being and that this you have time to look into this problem. But the
bottom line is that 3.1.x breaks my backup.

Regards,
Frank

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

Other repos to git? WAS Newlib/Cygwin now under GIT

[Frank Fesevur]

2015-03-10 16:38 GMT+01:00 Corinna Vinschen:
 I'm happy to inform you that the move of Newlib/Cygwin from the src CVS
 repository to the new, combined GIT repository is now final.

What is going to be the policy on cygwin-apps CVS repos? Are they
going to be converted to git as well?

I am working on a new version of shutdown. When the cygwin setup
repo was converted to git I converted the small CVS shutdown repo to
git and worked from there.

At the moment my work in progress can be found at
https://github.com/ffes/cygwin-shutdown but I gladly push that repo to
sourceware as well. Or maybe the admin of sourceware wants to use this
repo to set it up.

Regards,
Frank

Re: Other repos to git? WAS Newlib/Cygwin now under GIT

[Frank Fesevur]

2015-03-11 16:45 GMT+01:00 Corinna Vinschen:
 Are you happy with github?  If so, there's no reason to duplicate
 the repo on sourceware.  We can just make the crusty CVS repo R/O.

 Or, if you rather switch to sourceware, I can mirror your github
 repo and then we simply define the sourceware repo as master repo.
 You have an account on sourceware anyway, afaics.

I'm very happy with github.

It is just that when I took over the package from you, you preferred
the repo on sourceware.
https://www.cygwin.com/ml/cygwin/2013-05/msg00311.html

So if you don't mind, it fine to me to keep the new repo on github.

Regards,
Frank

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4

[Frank Fesevur]

2015-02-25 13:51 GMT+01:00 Corinna Vinschen:
 Another important change in this release is a change to chmod.  As many
 of you experienced since Cygwin 1.7.34, chmod does not always affect the
 POSIX permission mask as returned by stat(2) or printed by ls(1), due to
 the improved POSIX ACL handling.  As a temporary workaround, chmod now
 checks if secondary groups and users in the ACL have more permissions
 than the primary group.  If so, the permissions of the secondary users
 and groups will be reduced according to the mask given by the new
 primary group permissions.  I.e, chmod 600 will remove all permissions
 from the primary group as well as all secondary user and group entries
 in the ACL.

I have problems running screen on my pc. When I start it, it complains
about the mode of the temporary directory.
Directory /tmp/uscreens/S-Frank must have mode 700.

With 1.7.35-0.3 I could not chmod the directory manually. I just
upgraded to 1.7.35-0.4 and now I can manually chmod the directory to
700 and start screen again.

But IFAIK previously (not sure when) screen was able to chmod the
directory itself, but now not anymore.

Regards,
Frank

--
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: ssh-host-config script sends /etc/passwd thru awk

[Frank Fesevur]

2015-02-18 15:00 GMT+01:00 Corinna Vinschen:
  The openssh is the 64-bit version, as in the stackexchange user's case.
  The issue is interesting, though. When I first installed the openssh, it
  offered me prev version of the package, even though I was installing from
  the net. Re-running the installer picked the current version.
  Setup.exe glitch?

 No idea.  Mirror problem?  I never encountered the problem myself.

Seen this behavior as well last week, when I installed a new package.
But didn't take real notice until I read this thread.

At this moment I don't have cvs2svn installed. When I select it in
setup it will show 2.3.0-1, which is mentioned as [prev] in the
downloaded setup.ini. When I click it again it will select 2.4.0-1,
the current version in setup.ini

Regards,
Frank

--
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: [HEADSUP] Moving setup sources to git

[Frank Fesevur]

2015-02-10 14:55 GMT+01:00 Vin Shelton:
 git clone cygwin.com:/git/cygwin-setup.git
 Cloning into 'cygwin-setup'...
 Permission denied.
 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

I assume that you (just like me) didn't have write access to the
original CVS repo.

This worked for me:
git clone git://cygwin.com/git/cygwin-setup.git

Regards,
Frank

Re: [HEADSUP] Moving setup sources to git

[Frank Fesevur]

2015-02-09 17:24 GMT+01:00 Corinna Vinschen:
 please don't check in anything to the setup CVS repo anymore.

 I just created a git repo for setup:

   git clone cygwin.com:/git/cygwin-setup.git

Just to let you know that the anonymous read-only access works:
git clone git://cygwin.com/git/cygwin-setup.git

But I tried to build setup and I have a problem with the dependencies.

README says I need various mingw libs. But if IIRC mingw is not
recommended anymore. I have installed mingw64 and the mingw64 variants
of those libs. But there is no mingw64 variant of liblzma. I've
installed all 5 packages containing liblzma, but configure seems to
be unable to find it.

Do I still need the original mingw to compile setup or is the README outdated?

Regards,
Frank

Re: [HEADSUP] Moving setup sources to git

[Frank Fesevur]

2015-02-09 20:46 GMT+01:00 Achim Gratz:
  HOW TO BUILD:
  -
  Setup should build out-of-the-box on any Cygwin environment that has all the
  required packages installed:
 -  - mingw-gcc-g++
- make
 -  - mingw-bzip2
 -  - mingw-libgcrypt-devel
 -  - mingw-liblzma-devel
 -  - mingw-zlib
 -  - and all packages that are dependencies of the above, i.e.  
 gcc-mingw-core,
 -mingw-runtime, binutils, w*api, etc.
 +  - mingw64-gcc-g++
 +  - mingw64-bzip2
 +  - mingw64-libgcrypt
 +  - mingw64-xz
 +  - mingw64-zlib
 +  - and all packages that are dependencies of the above
- upx (optional)

Thanks, mingw64-xz did the trick.

Frank

Re: RFC: 1.7.33 problem with user's home directory

[Frank Fesevur]

2014-11-11 1:45 GMT+01:00 Andrey Repin:
 I see literally zero reason to maintain separate, cygwin-specific home
 directory.

I think I have to disagree with you. When mixing MSYS, msysGit and
Cygwin in the same home directory the dot-files can become a problem.
Especially when it comes to line ending in those files and the line
ending setting in .gitconfig.

Regards,
Frank

--
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: HEADSUP Maintainers: Stale packages on sourceware

[Frank Fesevur]

2014-10-29 14:42 GMT+01:00 Yaakov Selkowitz:
 Please find attached a list of old package tarballs which are not listed
 anywhere in setup.ini, meaning that they are not listed as a previous,
 current, or test package, and cannot be installed with setup.  These files
 consume a total of over 1.3Gib.

 Do maintainers have any objections to these being removed?

No problem.

Regards,
Frank

Re: vim can't write /etc/hosts

[Frank Fesevur]

2014-09-07 17:00 GMT+02:00 Andrey Repin:
 Adding to what other people said, most self-respecting antivirus applications
 explicitly block access to system hosts file.
 For obvious reasons.
 If you absolutely NEED to modify it, and can't resolve your issues in any
 other way, disable hosts file protection first.

Just to make sure I just disabled Kaspersky and tested again. That is
not the cause of this problem. It would have surprised me a lot, since
nano and the echo command work as expected.

Regards,
Frank

--
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: vim can't write /etc/hosts

[Frank Fesevur]

2014-09-05 4:33 GMT+02:00 Darik Horn:
 On Thu, Sep 4, 2014 at 4:33 PM, Frank Fesevur wrote:

 Why can't vim write the file, or even better the symlinked file? I'm
 quite sure editing the symlink works in Win7, but can try tomorrow.

 Starting C:\Cygwin\bin\mintty.exe through a Run As Administrator
 context doesn't produce an elevated bash prompt on my Windows 8
 workstation.

 Starting the Command Prompt (Admin) shortcut instead and running
 C:\Cygwin\bin\bash.exe --login inside should give you the expected
 behavior.

There is no difference (for me) between starting mintty or cmd as administrator.

With Win7 it *has* worked but not anymore. This method is *the* way
for me to change the hosts file, because of the short path.

nano /etc/hosts works without a problem on both Win7 and Win2012R2
(no Win81 at the office). The described echo command works fine. So
write access should not be the problem.

Only vim has these problems with the hosts file.

I don't know if it is relevant, but I've added noacl to the /cygdrive
entry of my fstab.

Regards,
Frank

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

vim can't write /etc/hosts

[Frank Fesevur]

Hi,

On my Win81 machine I tried to edit /etc/hosts with vim. When I try to
write the file I get this error:
/etc/hosts E166: Can't open linked file for writing

Since /etc/hosts is a symlink to
/cygdrive/c/windows/System32/drivers/etc/hosts so I tried to edit the
file with the full path but that fails as well:
/cygdrive/c/windows/System32/drivers/etc/hosts E212: Can't open file
for writing

I did all this with my mintty started as administrator:
uid=1000(Frank) gid=513(Geen)
groups=513(Geen),0(root),544(Administrators),545(Gebruikers)

I can edit the file starting my Notepad++ as administrator and open file.

A bit surprising but this works:

Frank@PC7 /cygdrive/c/Windows/System32/drivers/etc
# echo # test  hosts

Why can't vim write the file, or even better the symlinked file? I'm
quite sure editing the symlink works in Win7, but can try tomorrow.

Regards,
Frank

--
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: [ANNOUNCEMENT] Updated: mingw64-{headers,runtime,winpthreads} w32api-* 3.2.0-1

[Frank Fesevur]

2014-09-01 13:50 GMT+02:00 JonY:
 Now released for both 32bit and 64bit Cygwin:

 mingw64-*-headers-3.2.0-1
 mingw64-*-runtime-3.2.0-1
 mingw64-*-winpthreads-3.2.0-1
 w32api-headers-3.2.0-1
 w32api-runtime-3.2.0-1

I see my patch is in included this release. Thanks for updating!

Now I have no excuse anymore not to update the shutdown package ;-)

Regards,
Frank

--
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: rsyncd broken

[Frank Fesevur]

2014-08-25 9:46 GMT+02:00 Frank Fesevur:
 2014-08-22 14:42 GMT+02:00 Frank Fesevur:
 I will try a self build vanilla rsync.exe 3.1.1 this weekend or early
 next week and see how that works.

 I have tried my own build 3.1.1 last night and it fails with the same
 errors. I will investigate this.

Made a bit of progress. When I comment out the lines uid = 0 and gid =
0 from my /etc/rsyncd.conf v3.1.1. seems to work again, although I
haven't tried on our production server yet. I rather wait with that
until the weekend when there is not much to backup. I have not found
out why this behavior has changed since v3.0.9.

Another thing that surprises me is that the setuid() fails with an
errno 5, which is EIO. That error is not mentioned on this man page
http://linux.die.net/man/2/setuid What do you think? Is this setuid()
error a cygwin specific problem or should I ask upstream?

Regards,
Frank

--
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: rsyncd broken

[Frank Fesevur]

2014-08-22 14:42 GMT+02:00 Frank Fesevur:
 I will try a self build vanilla rsync.exe 3.1.1 this weekend or early
 next week and see how that works.

I have tried my own build 3.1.1 last night and it fails with the same
errors. I will investigate this.

Regards,
Frank

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

rsyncd broken

[Frank Fesevur]

Jari,

As I reported earlier rsync 3.1.0 is broken on cygwin.
http://www.cygwin.com/ml/cygwin/2014-06/msg00212.html
http://www.cygwin.com/ml/cygwin/2014-06/msg00442.html

Any news on that issue yet?

We run cygwin rsync daemons on our Windows servers and have a remote
Ubuntu server that backups the important data using rsnapshot. Earlier
this week I accidentally upgraded from 3.0.9 to your 3.1.0 on one of
our servers and that night the backup failed with these (client side)
error.

@ERROR: setuid failed
rsync error: error starting client-server protocol (code 5) at
main.c(1653) [Receiver=3.1.0]
ERROR: /usr/bin/rsync returned 5 while processing
rsync://192.168.202.230/backup-d/DataWeb/
@ERROR: setuid failed
rsync error: error starting client-server protocol (code 5) at
main.c(1653) [Receiver=3.1.0]
ERROR: /usr/bin/rsync returned 5 while processing
rsync://192.168.202.230/backup-d/wwwroot/

I reverted to 3.0.9 and it works as expected again.

But these error don't seem to be related to the 3.1.0 performance
issues, so do you have any idea why it fails? Could the additional
debian patch you've added cause this?

I will try a self build vanilla rsync.exe 3.1.1 this weekend or early
next week and see how that works.

Regards,
Frank

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

man doesn't work after update

[Frank Fesevur]

Hi,

Today I updated a server and ran into a problem.

$ man shutdown
man: can't execute iconv: No such file or directory
man: command exited with status 127: iconv -c -f UTF-8 -t
ISO-8859-1//TRANSLIT | (cd /home/Administrator  LESS=-ix8RmPm Manual
page shutdown(8) ?ltline %lt?L/%L.:byte %bB?s/%s..?e (END):?pB %pB\%..
(press h for help or q to quit)$PM Manual page shutdown(8) ?ltline
%lt?L/%L.:byte %bB?s/%s..?e (END):?pB %pB\%.. (press h for help or q
to quit)$ MAN_PN=shutdown(8) less -s)

After manually installing libiconv (libiconv2 was already installed)
the problem disappeared, so apparently there is a dependency missing
for man-db.

Regards,
Frank

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