Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)
On Thu, May 17, 2018 at 01:54 PM, L A Walsh wrote: > Very wierd. It triggers so fast, and whatever is causing it, likely > happens on a probe by 'ls' before ls even displays any output. > > I 'can' go into the same directory and do a "echo *" (or better, > printf "%s\n" * --- and that doesn't trigger it. > > I think I also triggered it once with 'tree'. Very annoying. > You could try writing a small C program that does a readdir of that directory and lstat of each file in it, logging what it's about to do before each step. That would let you narrow down which entry is triggering it, if that is indeed the cause. I think Michel LaBarre's suggestion of running chkdsk and sfc is a good one; strace also might help. -- 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: Update CoreUtils
On Tue, May 13, 2014 at 11:04 AM, Christopher Faylor wrote: > On Tue, May 13, 2014 at 09:59:03AM -0500, Steven Penny wrote: >> . . . > > Funny how you're saying "We" as if you are actually contributing > anything other than criticism. > I started a thread, at one point, to ask about a newer version of git. I offered to try to create a build, if it would help, even though while I have over a decade of experience in the software industry I have no experience as a Cygwin package maintainer. I also found that Steven Penny had offered, six months or a year before my thread, to build it. Adam Dinwoodie stepped up and offered to take over as maintainer. He got a build out in short order, but there was a glitch in either the cygwin dll or in openssl, I forget which, that caused long-running git clones to fail. Once that was fixed, everything seemed to be working except for something with git-cvs. I've never used git-cvs, and haven't used CVS since early 2009, so I didn't know how I could help with testing or resolving that issue. If I could have, I would have. I continued to use Adam's git build of 1.8.5.2 for the next couple of months, but it slowly started to bother me more and more that I was using a beta build. I didn't want to go back to git 1.7.9 because that version is well over two years old now (although, admittedly, I never had trouble with it). So I installed the native Windows git (msysgit) 1.9.2 from git-scm.org. It took a bit of configuring to get it to play nice with Cygwin. I need git because all my company's projects are in git (nearly; a few stragglers are still using svn). I wish there was a Cygwin build that was, say, a year old or less. (I still have one problem, that occasionally when it runs an external tool, it uses its msys bash which doesn't understand SHELLOPTS=igncr, which I need because of some stupid \r characters in the shell scripts of npm from nodejs.) I love Cygwin. I've been a happy user for years. Cygwin bash makes using Windows tolerable, which makes my life better. I deeply appreciate everything you all do, and I know that you're volunteers. I have no claim on your time, or your effort. If I have to build a few things myself, or use another version, I can do that. But it does look like some people have tried to help. I'm sorry I wasn't able to be of more help. There's no need for a reply to this. If you read this far, then thank you for your time, and thank you for all you do. -- 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: Maintainer for git?
On Wed, Feb 26, 2014 at 4:05 AM, Frank Fesevur wrote: > 2014-02-21 1:18 GMT+01:00 Adam Dinwoodie: >>> - Install git-cvs and the assorted dependencies mentioned in its >>> setup.hint, and verify you can clone the Cygwin CVS repository. I've >>> not managed to do this without hitting errors, but I suspect that's >>> because I'm using the tool incorrectly. >> >> I've tried this. I have `git cvsimport` seemingly working on the >> current Git 1.7.9 build, while my build reports the following SHA1 >> error: > > Probably not going to solve this issue (I can't anything about CVS in > the changelog), but you noticed that 1.9.0 had been released recently? > > Regards, > Frank > Has there been any movement at all on git in the last six weeks? What is "git-cvs"? There's no cygwin package by that name listed by setup.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
Re: setting cygwin terminal (mintty) title from a very remote system
On Fri, Apr 11, 2014 at 4:00 PM, Adam Dinwoodie wrote: > On Fri, Apr 11, 2014 at 12:13:07PM -0700, Ross Boylan wrote: >> >> echo -ne '\e]0;Title\a' >> > > [The] title will stay the same if something intercepts that sequence, and it > will probably appear to stay the same if something resets it immediately > (many Bash shell prompts do just that). > The fact that something else might reset it *immediately after* you set it is really important. It can make it look like something you are trying doesn't work **when it actually does work**. I would suggest using a command like this to test setting it: echo -ne "\e[0;This is a test\a"; sleep 5 That way, the title, if it's getting set at all, will remain set for a few seconds before it gets reset, so you can see it. That will allow you to tell the difference between a problem where the escape sequence is never reaching mintty because something is eating it, and one where the escape sequence is getting through just fine, but something, like the bash PS1 prompt, is immediately overwriting it. Good luck. -- 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: Win32 error 109
On Tue, Mar 4, 2014 at 6:44 PM, Wm. David Bentlage wrote: > I occasionally get errors like the following and don't understand > what's going on. Is there a way to correct this? > > user@machine /w/dir > $ tail -n1 safe*i | grep -i root | wc > 6 24 534 > 70 [main] bash 7012 sig_send: error sending signal -34 to pid > 7012, pipe handle 0x98, Win32 error 0 I've also seen this. In fact, I just saw it today, for the first time. It happens intermittently. $ uname -a CYGWIN_NT-6.1-WOW64 S1DMZG2 1.7.28(0.271/5/3) 2014-02-09 21:06 i686 Cygwin -- 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: g77 on cygwin64
On Wed, Feb 12, 2014 at 12:16 PM, Andrey Repin wrote: >> The strange thing is that gfortran does compile the code, but >> once compiled, the executables have strange behavior mainly involving >> problems reading in data files. ... > > And this is finally the information, that we can work with. > My wild guess is that your "colleagues" making certain assumptions about > files, that not always true on other systems. > I.e. opening a file in text mode, and then treating [its] data as binary ... Since the problem occurs going from 32-bit to 64-bit Cygwin, it sounds to me like all-the-world's-a-VAX syndrome. I bet there are places where it reads from files and assumes that if it reads N words into integers, that is N 32-bit quantities, or something like that. I haven't written any Fortran since the 1980s, but I bet there are types that have changed size due to the switch to 64-bit and that results in reading incorrect values from files, including reading some of them from the wrong file offsets, and hitting end-of-file at a different point. Are there any switches to gfortran that control this? I took a brief look, and the only thing I saw was the -finteger-4-integer-8 option and friends, but that sounds like going the opposite direction you want to go, and the -ff2c option that generates C code. You could run the code through g77 on 32-bit, gfortran on 64-bit, and compare the C code generated for the file handling. But I suspect that's more hassle than you want to get into; it doesn't sound like fun to me. Good luck. -- 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: Maintainer for git?
On Wed, Jan 29, 2014 at 10:35 AM, Adam Dinwoodie wrote: > On Tue, Jan 28, 2014 at 12:11:02PM +0100, Corinna Vinschen wrote: >> as soon as we release the next Cygwin version 1.7.28, which is due very >> soon now. >> > I've just tested this -- the clone is [...] working just fine with > the 2014-01-28 snapshot. I've not tested the snapshot on x86_64, but I > can try to find time to do that if it'd be useful. > Just curious where we stand with this now that 1.7.28 is out. Does it still need testing on x86_64? I currently have 32-bit cygwin installed on a 64-bit machine, but I'd be happy to install 64 (they can be installed side-by-side, correct?) if it would help with testing the new git. Regards, David -- 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: using spawn functions to avoid fork() errors
>>> On 2/6/2014 8:50 AM, Steven Bardwell wrote: However, on my 64-bit install, the spawnv() call is returning with an error -- 'No such file or directory' -- when I try to spawn /bin/sh. A few things come to mind as possibilities to check, or try. First, there is a certain amount of magic that cygwin does to treat /bin/sh.exe and /bin/sh the same. What happens if you spawn /bin/sh.exe instead of /bin/sh? Second, what happens if you use spawnvp instead of spawnv? Although, from the strace excerpt it doesn't look like it's actually having trouble finding the executable, so those probably aren't it. Still, worth checking, perhaps. Third, are you certain you are NULL-terminating the array of arguments? If you aren't doing so explicitly, it is possible there happened to be a NULL pointer just after the arguments in memory for the 32-bit version, so it happened to work, but that didn't happen for the 64-bit version. The argv array must have a NULL at the end of it. Fourth, what are you passing to the mode parameter of spawnv? Or, fifth, I dunno what the problem is. Those are my only ideas. Good luck. David -- 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: Newbie Cygdrive questions
It may be useful to know, if you do not already, that the cygpath utility can be used to convert between Windows and Unix paths. cygpath -u X:/INBOUND/CWSCRIPTS/myscript.sh will give you /cygdrive/x/INBOUND/CWSCRIPTS/myscript.sh, and cygpath -w /cygdrive/x/INBOUND/CWSCRIPTS/myscript.sh will give you X:\INBOUND\CWSCRIPTS\myscript.sh You can also use cygpath -m if you prefer forward slashes, even in your Windows paths. On Thu, Feb 6, 2014 at 3:03 PM, Richard wrote: > > On Thu, 6 Feb 2014, mrushton wrote: >> >> >> To access this shared X drive under Cygwin it seems I have to do this : >> >> /cygdrive/X/INBOUND/CWSCRIPTS/myscript.sh >> >> >> Is this correct ? Is there a better way ? >> >> And C: seems to be /cygdrive/C/ >> > > A BETTER way? > > This has nothing per se to do with Cygwin, but, briefly: > > Standardize all your systems on something YOU can control. For example, I > always create a top-level directory called l (that's the letter, not the > numeral) which stands for "local", and another called nfs, which simply > means a remote mount - could be real nfs or Samba - and then make links > within these directories to wherever they need to go. That way, all disk > space is available via either: > > /l/ > > or > > /nfs/ > > as appropriate. > > And there's never any confusion over which is which - and drive letters can > be completely avoided as desired, or not. > > ...All (many!) good System Administrators do things similar to this... > > Richard > > > -- > 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 > -- 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: Maintainer for git?
On Wed, Jan 29, 2014 at 1:10 PM, Corinna Vinschen wrote: > On Jan 29 12:13, David Conrad wrote: >> On Wed, Jan 29, 2014 at 10:35 AM, Adam Dinwoodie wrote: >> > On Tue, Jan 28, 2014 at 12:11:02PM +0100, Corinna Vinschen wrote: >> >> Chris and I discussed this problem further and we applied a patch to the >> >> Cygwin DLL which saves and restores the FPU state and XMM registers on >> >> 32 bit as well when a thread gets interrupted for signal handling. >> >> . . . >> >> I'd be grateful if you could do some more testing as well. Please >> >> revert your OpenSSL package to 1.0.1f-1 via setup, and then fetch the >> >> latest 2014-01-28 Cygwin snapshot DLL from http://cygwin.com/snapshots/, >> >> . . . >> > >> > I've just tested this -- the clone is failing ... with the current cygwin >> > package ... and working just fine with the 2014-01-28 snapshot. ... Well, one way to test with the new Cygwin snapshot DLL is just to wait until it becomes the new release. :) I just tested git cloning ffmpeg and linux, with Adam's git 1.8.5.2, on 32-bit Cygwin 1.7.28, and using the prior version of the OpenSSL package, 1.0.1f-1. It worked like a charm. I'm guessing the plan is to roll out a "new" OpenSSL package that is compiled with SSE2 enabled again, and to release the updated build of git? David -- 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: Maintainer for git?
On Wed, Jan 29, 2014 at 10:35 AM, Adam Dinwoodie wrote: > On Tue, Jan 28, 2014 at 12:11:02PM +0100, Corinna Vinschen wrote: >> Chris and I discussed this problem further and we applied a patch to the >> Cygwin DLL which saves and restores the FPU state and XMM registers on >> 32 bit as well when a thread gets interrupted for signal handling. >> . . . >> I'd be grateful if you could do some more testing as well. Please >> revert your OpenSSL package to 1.0.1f-1 via setup, and then fetch the >> latest 2014-01-28 Cygwin snapshot DLL from http://cygwin.com/snapshots/, >> . . . > > I've just tested this -- the clone is failing ... with the current cygwin > package ... and working just fine with the 2014-01-28 snapshot. ... I tried to test this as well, but when I tried to move the existing cygwin1.dll out of the way and drop the new one in, I got "Access is denied.", even when running a cmd.exe Windows shell as Administrator, without any cygwin bash shell running, and ditto for trying it after a reboot and not having run anything cygwin since the boot. I'm not sure what Vulcan nerve pinch I'm missing here to convince Windows to let me at these files. > I have to say, I'm really impressed with your debugging here! Ditto! All the best, David -- 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: Maintainer for git?
On Mon, Jan 27, 2014 at 10:12 AM, Chris O'Bryan wrote: > On Sun, Jan 26, 2014 at 4:45 PM, Steven Penny wrote: >> On Sat, Jan 25, 2014 at 5:59 AM, Corinna Vinschen wrote >>> For the time being, I've build a new OpenSSL version 1.0.1f-2 with the >>> "no-sse2" flag. With this version I could clone the linx repo without >>> error. Please give it a try. >> >> I can confirm this fixes my problems as well >> > > This fixed my issue, too. Good hunch on the SSE stuff! > With the new OpenSSL from Corinna I was able to clone both the linux and ffmpeg repos with Adam's latest git-1.8.5.2. Many thanks to Corinna, Adam, and all those who have tested this. I hope to see a new git on the mirrors soon! Cheers, David -- 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: Maintainer for git?
On Mon, Jan 20, 2014 at 8:31 PM, Steven Penny wrote: > On Mon, Jan 20, 2014 at 7:26 PM, Balaji Venkataraman wrote >> But the cygcrypto dll version bug referred here[1] is still present as >> this version (1.8.5.2-1) is linked w/ cygcrypto-1.0.0.dll > > Are you certain the bug is present in Adam’s version? He has tested it here > > http://cygwin.com/ml/cygwin/2014-01/msg00085.html I just wanted to add, I have been using Adam's version for the last couple of days without any issues. (The x86 variant.) The only problem I had was when I went to install it using Steven's instructions: > Also for anyone interested in testing this is the install, pretty simple > > wget tastycake.net/~adam/cygwin/x86/git/git-1.8.5.2-1.tar.xz > tar -x -C / -f git-1.8.5.2-1.tar.xz When I went to untar it, I got errors trying to hardlink git.exe and git-upload-archive.exe to git-receive-pack.exe in the /usr/bin directory. (I had previously uninstalled git using setup-x86.exe, so as to install it "clean".) I ended up running Windows cmd.exe and using mklink /H to make the links. David -- 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: Maintainer for git?
On Wed, Jan 15, 2014 at 5:55 AM, Adam Dinwoodie wrote: > On Sun, Jan 12, 2014 at 01:33:17PM +, Adam Dinwoodie wrote: >> On 12 January 2014 02:58, Steven Penny wrote: >> > . . . >> > # git push >> > fatal: Unable to find remote helper for 'https' >> >> . . . >> Thank you for testing and reporting! > > This should now be fixed, with a new version uploaded to the same place. > If you'd care to try again I'd be very grateful! > > (In case anyone's interested, it appears that if Git is compiled without > openssl-devel or equivalent installed, it will silently fail to compile > support for https connections.) It sounds like we're quite close to having a new version available? I know there's one on Cygwin Ports or I could build it myself, of course, but I'm hoping to see a new official build soon. Not to prod, but . . . *prod*. :) Thanks for all you do (all of you, Cygwin folks), David -- 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
Maintainer for git?
Hi, Is there currently a maintainer for the git package? The cygwin version is at 1.7.9, which is from January 2012, and the latest version is 1.8.5.2. If the reason it hasn't been updated is that there is no maintainer, I *may* be able to help create a newer package. All the best, David Conrad -- 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
