ls doesn't work after installing keepassx
Yesterday i installed keepass and 'ls' stopped working: 53103107v@DES-62424 /tmp $ ls 53103107v@DES-62424 /tmp $ strace ls >>> window pops up with a message like entry point for acl_extended_file in >>> the dll C:\cygwin64\bin\ls.exe. --- Process 8472 created --- Process 8472 loaded C:\Windows\System32\ntdll.dll at 7FFD7C58 --- Process 8472 loaded C:\Windows\System32\kernel32.dll at 7FFD7AA3 --- Process 8472 loaded C:\Windows\System32\KernelBase.dll at 7FFD797A --- Process 8472 loaded C:\cygwin64\bin\cygwin1.dll at 00018004 --- Process 8472 loaded C:\cygwin64\bin\cygintl-8.dll at 0003FDFD --- Process 8472 loaded C:\cygwin64\bin\cygiconv-2.dll at 0003FE03 --- Process 8472, exception c139 at 7FFD7C66CDD0 --- Process 8472, exception c139 at 7FFD7C66CDD0 --- Process 8472 exited with status 0xc139 the same for keepass 53103107v@DES-62424 /tmp $ keepassx.exe 53103107v@DES-62424 /tmp $ strace keepassx.exe >>> window pops up with message like entry point for frexpl in the dll >>> C:\cygwin64\bin\cygstdc++-6.dll not found --- Process 12204 created snip --- Process 12204 loaded C:\cygwin64\bin\cygxcb-1.dll at 0003FC53 --- Process 12204, exception c139 at 7FFD7C66CDD0 --- Process 12204, exception c139 at 7FFD7C66CDD0 --- Process 12204 exited with status 0xff I'm not administrator so i ran setup with -B option, i ran rebaseall, looks like i don't have cygwin libraries in path: 53103107v@DES-62424 /tmp $ echo $PATH | sed 's/:/\n/g' | while read f; do find "$f" -maxdepth 1 -type f | grep "/cyg.*cyg.*dll" && echo " $f"; done 53103107v@DES-62424 /tmp I attach cygcheckout with some parts removed Regards 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: ls doesn't work after installing keepassx
On 19/05/2016 09:44, David Carricajo wrote: Yesterday i installed keepass and 'ls' stopped working: 53103107v@DES-62424 /tmp $ ls 53103107v@DES-62424 /tmp $ strace ls something went wrong on your installation/upgrade: cygwin2.5.1-1OK but 3327k 2016/01/24 C:\cygwin64\bin\cygwin1.dll - os=4.0 img=0.0 sys=5.2 "cygwin1.dll" v0.0 ts=2016-01-24 11:26 Cygwin DLL version info: DLL version: 2.4.1 Have you run the setup with cygwin process running ? I suggest to reinstall the cygwin package Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] curl 7.49.0-1
The following packages have been uploaded to the Cygwin distribution: * curl-7.49.0-1 * libcurl4-7.49.0-1 * libcurl-devel-7.49.0-1 * libcurl-doc-7.49.0-1 * mingw64-i686-curl-7.49.0-1 * mingw64-x86_64-curl-7.49.0-1 curl is a command line tool and library for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, and FILE. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate...), file transfer resume, proxy tunneling and a busload of other useful tricks. This is an update to the latest upstream release: https://curl.haxx.se/changes.html Please note that the security advisory attached to this release does NOT apply to the Cygwin packages; this should be considered an ordinary bugfix and feature release. -- Yaakov -- 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: Show Symbol Table for OMF (.obj)?
Am 16.05.2016 um 22:05 schrieb Yaakov Selkowitz:
On 2016-05-16 14:10, Benjamin Cao wrote:
I am curious to know if there is a command that will display a symbol
table for
*.obj files. It seems as if commands such as "nm" or "objdump" do not
do this.
I get "File format not recognized".
You may want to try i586-pc-msdosdjgpp-{nm,objdump} from the
djgpp-binutils package.
That won't help, because DJGPP uses COFF, not OMF.
Actually, I don't think binutils ever supported OMF.
--
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
Request for python-nose
Yaakov, when you have a moment, please could you bring python-nose across from ports. Many thanks in advance, Dave. -- 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: Why does ldd not show cyg*.dll in its output?
Am 16.05.2016 um 19:50 schrieb Yaakov Selkowitz: On 2016-05-16 10:42, Warren Young wrote: $ ldd `which ls` ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd16fb) KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd16b8) KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd13f5) WFM: $ /bin/ldd /bin/ls ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x77c9) kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x77a7) KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x7fefdb1) cygwin1.dll => /usr/bin/cygwin1.dll (0x18004) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3d4e0) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3d8b5) Does not WFM: $ ldd /usr/bin/ls.exe ntdll.dll => /cygdrive/c/windows/SYSTEM32/ntdll.dll (0x7ffe93c0) KERNEL32.DLL => /cygdrive/c/windows/system32/KERNEL32.DLL (0x7ffe912d) KERNELBASE.dll => /cygdrive/c/windows/system32/KERNELBASE.dll (0x7ffe9031) (no different results from /bin/ls or /bin/ls.exe, either). This is with ldd.exe from cygwin-2.5.1-1, on Win10 64bit, installed into c:\cygwin64 -- 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
Necessity for the assignment form
Hello, I found a bug and I am willing to submit a patch (under winsup/cygwin). But before doing that, I was asked from my employer to clarify some points. https://cygwin.com/contrib.html says that the assignment form is required "if your change is going to be a significant one in terms of the size of your code changes". So the questions are: 1. Who is going to determine if the change is "a significant one"? 2. In fact, my patch is just two lines of modifications, so I believe that it is not "a significant one". Is it okay to send such a small patch without the assignment form? Thanks in advance, KOBAYASHI Shinji. -- 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 remove pesky persistent +x bits that chmod -x won't remove
I think I have an ACL inheritance problem. Here’s the scenario: $ ls -l Protocol.md ## Boo, bad permissions; shouldn’t be +x! -rwxr--r--+ 1 Warren Warren 4.3K May 19 18:41 Protocol.md* $ chmod -x Protocol.md $ ls -l Protocol.md ## Still +x! Did I stutter? -rwxr--r--+ 1 Warren Warren 4.3K May 19 18:41 Protocol.md* $ icacls.exe Protocol.md ## Okayyy…lots of X’s Protocol.md NULL SID:(DENY)(Rc,S,X,DC) MOSSYMAZE\Warren:(R,W,D,WDAC,WO) MOSSYMAZE\Warren:(DENY)(S,X) NT AUTHORITY\SYSTEM:(DENY)(S,X) BUILTIN\Administrators:(DENY)(S,X) MOSSYMAZE\Warren:(RX) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) Everyone:(R) Successfully processed 1 files; Failed processing 0 files $ icacls Protocol.md /reset ## Nuke the X’s! processed file: Protocol.md Successfully processed 1 files; Failed processing 0 files $ ls -l Protocol.md ## Still +x! -rwx---r-x+ 1 Warren Warren 4.3K May 19 18:41 Protocol.md* $ chmod -x Protocol.md ## Ah, *now* it will listen to me. $ ls -l Protocol.md -rwr--+ 1 Warren Warren 4.3K May 19 18:41 Protocol.md $ icacls.exe Protocol.md ## Clear as mud Protocol.md NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) MOSSYMAZE\Warren:(I)(F) Everyone:(I)(RX) I assume this is happening because something farther up the directory tree keeps reapplying the +x bit to this file, but I can’t see what from the icacls output. Is there a tool that will give me a tree view so I can see what’s applied at each level? Failing that, do I just run icacls on every parent directory of this file? And then what? I don’t think I dare /reset all permissions clear back to the root. This 2-step permission fix is getting old, because the bad permissions come back again every time something rewrites one of the affected files. For what it’s worth, setfacl -bk followed by a chmod -x sometimes always fixes this. I’m just using icacls above because its output seems clearer, probably because it’s NTFS-native, not reinterpreting everything through a POSIX lens. -- 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: Why does ldd not show cyg*.dll in its output?
On May 19, 2016, at 5:21 PM, Hans-Bernhard Bröker wrote: > > Does not WFM: [snip] > This is with ldd.exe from cygwin-2.5.1-1, on Win10 64bit, installed into > c:\cygwin64 That’s identical to my system. I was going to attach the output of “strace ldd `which ls`” but that leaks too much detail about my system. Any idea what I should be looking for in it? I get about 400 lines of mud. -- 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: Necessity for the assignment form
On May 19, 2016, at 6:44 PM, KOBAYASHI Shinji wrote: > > my patch is just two lines of modifications, so I believe > that it is not "a significant one". Is it okay to send such a small > patch without the assignment form? How about you just give the line of code and explain what’s wrong with it? Then someone with checkin rights can reimplement your change from your prose description. -- 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
Help debugging a dll issue
Dear Cygwin friends -- I am trying to get pypy to build under cygwin. (It used to do so, but has not been maintained.) I am very close, but there is something quite odd happening when trying to access the large dll that the system builds: the first call into that dll goes wild and causes a segfault. The issue seems to lie with run-time linking, for I can use dlopen to open the dll and then dlsym to look up the function, and I get the same bad address. I see nothing wrong from nm and objdump. The dll is about 70 million bytes long, so I can't really post it, but if you want to have a crack at this, we can find some mutually agreeable place and I can tell you the entry point I am trying to access. I have found that if I patch the indirection in the associated .exe file to refer to the actual address of the function, then the program runs, so it's just this one linkage that is not working (apparently). Very mysterious to me. Regards -- Eliot Moss -- 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
Invalid tm_zone from localtime() when TZ is not set
> Warren Young wrote: > How about you just give the line of code and explain what’s wrong with it? > Then someone with checkin rights can reimplement your change from your prose > description. Thank you for your suggestion. So I try to describe the problem: Current localtime() can return invalid tm_zone when used with non-English Windows and the TZ environment variable is unset. This leads to a failure of importing time module in Python 3: % (unset TZ; python3 -c "import time") Traceback (most recent call last): File "", line 1, in SystemError: initialization of time raised unreported exception Although most users set the TZ environment variable, tox (>= 2.0) drops most environment variables including TZ by default when invoking test environments. So the users of tox on non-English Windows may suffer from this problem. localtime() calls tzsetwall() when TZ is not set. In tzsetwall(), the StandardName and DaylightName member values retrieved by GetTimeZoneInformation() are checked with isupper() and copied to the char[] buffer used as the timezone name in tzparse(). However, the type of these member values are wchar_t and isupper() is defined only when isascii() is true. So it may happen that the char[] buffer contains invalid characters as a result of implicit cast from wchar_t to char. The return value of isupper() for non-ascii characters depends on other data, because an out of bounds access occurs for the small (128 + 256) table used in isupper(). I confirmed the above error on Japanese Windows with 64-bit Cygwin 2.5.0-1 and 2.5.1-1, but had no problem with 64-bit Cygwin 2.4.1-1 nor with 32-bit Cygwins. So, I propose to call isascii() to assure the wchar_t fits in the range of ASCII before calling isupper(). I have considered some other methods: 1. Using iswupper() instead of isupper(). - Although this method is effective for Japanese environments, it is not assured that the character iswupper() returns true fits in the range of ASCII. 2. Add (char) cast to the argument of isupper(). - This method assures that the copied characters are uppercase only. However, it may be different from original characters due to casting. So I think that adding isascii() calls is better than these methods. Regards, KOBAYASHI Shinji. -- 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: Necessity for the assignment form
On 20/05/16 01:44, KOBAYASHI Shinji wrote: I found a bug and I am willing to submit a patch (under winsup/cygwin). But before doing that, I was asked from my employer to clarify some points.https://cygwin.com/contrib.html says that the assignment form is required "if your change is going to be a significant one in terms of the size of your code changes". So the questions are: 1. Who is going to determine if the change is "a significant one"? 2. In fact, my patch is just two lines of modifications, so I believe that it is not "a significant one". Is it okay to send such a small patch without the assignment form? For Cygwin, the boundary between trivial and substantial is usually taken as ten lines. A two-line patch would probably be accepted without an assignment form. Dave. -- 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
