RE: ssh.exe on cygwin: Write error
Dear Cygwin list; So I've made some progress on the problem with ssh I started out trying to solve... unfortunately, it's got me in select.cc in Cygwin. Basically, the ssh.exe program operates as this: Ssh sets up a connection, and starts client_loop; client_loop monitors (in the debugging case) a single channel. It checks to see if input is to be read (from stdin in this case), and checks if there's data to write from an output buffer and also if select() says the outbound connection is writable. In the case of debugging, the network connection from ssh.exe to the server is on fd 3. If there's data to read, it reads it into a buffer. If there's data to send in the output buffer AND select() says that fd 3 is writable, then it calls packet_write_poll, which then calls roaming_write, which does a write() on the fd. If there's a failure to write(), then packet_write_poll sees what the error is. EAGAIN, EINTR, and EWOULDBLOCK (same as EAGAIN on Cygwin) are non-fatal. Any other error is fatal. In debugging, what happens is that the client_loop is processing away just fine. As it happens, it's reading more data than writing on stdin. It is happily writing data on the outbound socket, using write() as called by roaming_write as called by packet_write_poll. At some point, something ?bad? occurs. 1. Select() says that the fd 3 (outbound connection) is writeable to the network. 2. Write() goes to write, but gets an error 11 (EAGAIN). 3. Many (probably 50-100) calls to select() say that the socket is not writeable, and a packet trace on the server side confirm that the flow of packets has completely stopped. I can see that peek_socket() in select.cc is returning 'peek_socket: read_ready: 0, write_ready: 0, except_ready: 0' in the strace. 4. After some time (30 seconds) select() on fd 3 returns both readable+writable. It tries to read from fd 3, but it gets an error 104 (ECONNRESET). It subsequently tries to write on the socket, and also gets an error 104 (ECONNRESET). 5. Since the write() failed, it returns that to roaming_write, which returns it to packet_write_poll. This prints the fatal error "Write failed: connection reset by peer". 6. Interestingly, the server side has not issued a tcp/ip rst. In fact, from the server perspective, it just looks like the tcp/ip connection stalled (happens right at the error 11). The server side isn't shut down till some time later. 7. Definitely, the connection does get 'backed up' so to speak - i.e. I'm pushing more data than the internet connection can handle without blocking to process data, and I would expect select() and/or write() to fail waiting for the network to clear some buffers. That said, it's almost like the socket die's or needs to reset or something after the error 11 (EAGAIN). 8. I don't see any signals or timeouts happening. Also, I've retested with Cygwin 1.7.21 with no additional success. I'm going to keep looking, but any thoughts with the new information? Thanks, Devin -- 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: bzr problem
Katsumi Yamaoka writes: >> I'd venture to guess that the DLL(s) in question belong to a Python >> package. If so, does the rebaseall script you are using look at those >> libraries at all? > > As far as I can observe, those DLLs are listed in TEMP/rebase.lst > (that rebaseall temporarily generates), and `rebaseall -v' shows > that they are processed by `rebase'. Thanks. You could dump the contents of the rebase database then and check what the base address for this library is supposed to be. Chances are that it is very much higher than what your example of a fork fail shows. In my experience, such low base addresses indicate BLODA; however if a library is indeed rebased into this region it has almost zero chances of correctly forking in that address range. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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 with cvs binary?
The currently provided cvs executable does not work correctly, simple test case is: ~>export CVSROOT=/tmp/cvsroot ~>cvs init ~>cvs co -d /tmp/workdir . cvs [checkout aborted]: cannot make directory : No such file or directory ~>cygcheck -c cvs Cygwin Package Information Package VersionStatus cvs 1.12.13-10 OK ~>uname -a CYGWIN_NT-5.1 virt-winxp 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin The above should checkout the empty project to /tmp/workdir, but does not work with the binary provided via setup.exe. This does work correctly with a) cvs-1.12.13 rebuilt from sources, and b) with cvs v 1.11.22-1 downloaded from setup.exe. The expected result: ~>cygcheck -c cvs Cygwin Package Information Package VersionStatus cvs 1.11.22-1 OK ~>cvs co -d /tmp/work . cvs checkout: Updating /tmp/work cvs checkout: Updating /tmp/work/CVSROOT U /tmp/work/CVSROOT/checkoutlist U /tmp/work/CVSROOT/commitinfo U /tmp/work/CVSROOT/config U /tmp/work/CVSROOT/cvswrappers U /tmp/work/CVSROOT/editinfo U /tmp/work/CVSROOT/loginfo U /tmp/work/CVSROOT/modules U /tmp/work/CVSROOT/notify U /tmp/work/CVSROOT/rcsinfo U /tmp/work/CVSROOT/taginfo U /tmp/work/CVSROOT/verifymsg Mark -- 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: bzr problem
Achim Gratz wrote: > Katsumi Yamaoka writes: >> 0 [main] python2.7 1264 child_info_fork::abort: address space needed >> by 'math.dll' (0x80) is already occupied >> >> But it is sometimes: >> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap >> _ARC4.dll to same address as parent (0xBE) - try running >> rebaseall >> >> Rebaseall doesn't help. Reinstalling bzr+python doesn't, either. >> How can I fix this problem? > I'd venture to guess that the DLL(s) in question belong to a Python > package. If so, does the rebaseall script you are using look at those > libraries at all? As far as I can observe, those DLLs are listed in TEMP/rebase.lst (that rebaseall temporarily generates), and `rebaseall -v' shows that they are processed by `rebase'. 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
Re: Cygwin and x: directory
Greetings, Corinna Vinschen! > On Jul 12 20:09, Nellis, Kenneth wrote: >> On 07/12/2013 08:42 AM, Mikko Rapeli wrote: >> > >> > Hi Cygwin and git developers, >> > >> > Does following scenario show signs of bugs in Cygwin and/or git? >> > >> > # setup git repo >> > $ cd /tmp >> > $ mkdir foo && cd foo >> > $ git init >> > >> > # create x: directory >> > $ mkdir x: >> > $ ls >> > x: >> >> IMHO, this makes an interesting problem (unrelated to git): >> Shell script prompts user for file name. >> User enters "x:". >> Script proceeds as follows: >> $ mkdir tmpdir >> $ touch tmpdir/x: >> $ # useful work done here >> $ rm -r tmpdir >> rm: cannot remove `tmpdir/x:': No such file or directory >> rm: cannot remove `tmpdir': Directory not empty >> $ > That's a problem of how recursive rm works. It chdir's into > the subdirs it's working on and then calls "x:" which is recognized > as drive prefix of a windows path. Or a file stream with empty name. Which isn't allowed either, AFAIK. > `rm ./x:' works as expected. >> It would seem that touch and rm are following different >> rules regarding how files may be named. > No. > Corinna -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.07.2013, <23:42> 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: SVN::Ra problems
Greetings, David Rothenberger! > Mikko Rapeli wrote: >> As a workaround, I copied a full cygwin directory from another machine >> where subversion-perl is working with svn 1.7.10 packages, and this works. > I'm glad you got it working. >> With latest cygwin packages, including subversion 1.8, >> perl -e 'require SVN::Ra' works >> >> Downgrading to subversion 1.7.10 worked well a few weeks back but not >> anymore. > I tried downgrading to 1.7.10 this morning and perl -e 'require SVN::Ra' > worked fine for me. > [cygcheck from broken setup is]: >> Found: C:\Testwell\CTC\perl >> Found: C:\Apps\cygwin\bin\perl.exe >> Warning: C:\Testwell\CTC\perl hides C:\Apps\cygwin\bin\perl.exe >> cygcheck output from the working setup is: >> Found: C:\cygwin\bin\perl.exe >> Found: C:\Testwell\CTC\perl >> Warning: C:\cygwin\bin\perl.exe hides C:\Testwell\CTC\perl > I wonder if this is the reason? Perhaps Cygwin was picking up the wrong > perl? Without any "perhaps". > Anyway, I don't see anything else to explain this. It works fine for me. > It appears your subversion-perl installation was complete on the broken > installation. I don't know why it wouldn't be able to find that DLL. You made it that way. -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.07.2013, <23:40> 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
Problem binding OpenSSH_6.2p2 to IPV4 stack
After troubleshooting an AutoSSH problem last week, it appears that on
this 2003R2 box sshd cannot bind to the IPV4 stack! Rather, with the
default configuration it binds to IPV6 (and supports a loopback connection
fine), but a remote connection fails. When sshd is forced to bind IPV4
("Addressfamily inet"), sshd cannot start.
With default sshd config, connection to the autossh tunnel from a remote
system produces:
[remote system]
ssh_exchange_identification: Connection closed by remote host
[2003R2 server]
debug1: channel 2: connection failed: Connection refused
connect_to 127.0.0.1 port 2206: failed.
debug1: channel 2: free: ::1, nchannels 3
Any pointers on troubleshooting would be greatly appreciated, ..
TIA!
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ctrl-c to windows program causes mintty to hang [1.7.20 / win7]
On 7/15/2013 1:47 PM, Marvin wrote: FWIW, 1.7.20 and Windows 8 is no good as well. Try upgrading to 1.7.21. That reportedly fixes the problem. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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 to windows program causes mintty to hang [1.7.20 / win7]
FWIW, 1.7.20 and Windows 8 is no good as well. Anyway I can help on fixing this? -- View this message in context: http://cygwin.1069669.n5.nabble.com/ctrl-c-to-windows-program-causes-mintty-to-hang-1-7-20-win7-tp99346p100817.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: SVN::Ra problems
Mikko Rapeli wrote: > As a workaround, I copied a full cygwin directory from another machine > where subversion-perl is working with svn 1.7.10 packages, and this works. I'm glad you got it working. > With latest cygwin packages, including subversion 1.8, > perl -e 'require SVN::Ra' works > > Downgrading to subversion 1.7.10 worked well a few weeks back but not > anymore. I tried downgrading to 1.7.10 this morning and perl -e 'require SVN::Ra' worked fine for me. [cygcheck from broken setup is]: > Found: C:\Testwell\CTC\perl > Found: C:\Apps\cygwin\bin\perl.exe > Warning: C:\Testwell\CTC\perl hides C:\Apps\cygwin\bin\perl.exe > cygcheck output from the working setup is: > Found: C:\cygwin\bin\perl.exe > Found: C:\Testwell\CTC\perl > Warning: C:\cygwin\bin\perl.exe hides C:\Testwell\CTC\perl I wonder if this is the reason? Perhaps Cygwin was picking up the wrong perl? Anyway, I don't see anything else to explain this. It works fine for me. It appears your subversion-perl installation was complete on the broken installation. I don't know why it wouldn't be able to find that DLL. -- David Rothenberger daver...@acm.org QOTD: If it's too loud, you're too old. -- 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: Cygwin 1.7.21
Hi Cygwin friends and users, I just released Cygwin 1.7.21. This is mostly a bugfix release. What's new: --- - New API: rawmemchr. - Make cygcheck report when scanned DLLs are symlinks or are not meant for the current architecture (x86 vs. x86_64). See: http://cygwin.com/ml/cygwin/2013-07/msg00143.html Bug fixes: -- - Fix long-standing problem which allows to access files via ".." using an invalid POSIX path, for instance, `cd nonexistant/../existing_dir". Fixes: http://cygwin.com/ml/cygwin/2013-05/msg00222.html - Fix EFAULT when reading large clipboard. Fixes: http://cygwin.com/ml/cygwin/2013-06/msg00311.html - Fix creation of relative native symlinks. Fixes: http://cygwin.com/ml/cygwin/2013-06/msg00340.html http://cygwin.com/ml/cygwin/2013-07/msg00286.html - Update profiling code to latest from Mingw-w64. Allows profiling on x86_64 now and fixes http://cygwin.com/ml/cygwin/2013-06/msg00376.html - Fix character comparisons in certain scenarios within the functions glob(3), fnmatch(3), and regcomp(3). All Unicode chars beyond U+0100 are affected. - Fix problem with pty closing which manifested as a screen issue: See: http://cygwin.com/ml/cygwin/2013-06/msg00196.html Have fun, Corinna *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: SVN::Ra problems
Hi Mikko, On Mon, Jul 15, 2013 at 1:20 PM, Mikko Rapeli wrote: > As a workaround, I copied a full cygwin directory from another machine > where subversion-perl is working with svn 1.7.10 packages, and this works. > cygcheck output from the working setup is: > > Cygwin Configuration Diagnostics (snip) Please don't put the output of cygcheck in the body of the email. Attach it as a text file, as recommended by: > Problem reports: http://cygwin.com/problems.html Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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: SVN::Ra problems
As a workaround, I copied a full cygwin directory from another machine where subversion-perl is working with svn 1.7.10 packages, and this works. cygcheck output from the working setup is: Cygwin Configuration Diagnostics Current System Time: Mon Jul 15 11:59:04 2013 Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Testwell\CTC C:\Program Files\ARM\bin\win_32-pentium C:\Program Files\PC Connectivity Solution C:\Oracle\Client\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files\Microsoft Application Virtualization Client C:\Program Files\TortoiseSVN\bin C:\Program Files\cygwin\bin C:\Program Files\ARM\RVCT\Programs\4.1\561\win_32-pentium C:\Program Files\ARM\RVD\Core\4.1.1\25\win_32-pentium\bin C:\Program Files\ARM\RVI\Tools\4.1\32\programs\win_32-pentium C:\Program Files\ARM\Utilities\FLEXlm\10.8.5.0\1\win_32-pentium C:\Program Files\Microsoft SQL Server\100\Tools\Binn C:\Program Files\Microsoft SQL Server\100\DTS\Binn C:\Program Files\CMake 2.8\bin C:\Program Files\Dr. Memory\bin Output from C:\cygwin\bin\id.exe UID: 1793714(user)GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'user' PWD = '/cygdrive/c' CYGWIN = 'nodosfilewarning' HOME = '/home/user' HOMEPATH = '\' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\user\AppData\Roaming' ARMCC41LIB = 'C:\Program Files\ARM\RVCT\Data\4.1\561\lib' HOSTNAME = 'COMPUTER' ARM_ENABLED_PRODUCTS = 'C:\Program Files\ARM|RVDS/Contents/4.1/158:platform=win_32-pentium,encryption=none,extras_dir=professional\,regime=rel,capability=professional' ARMCC41BIN = 'C:\Program Files\ARM\RVCT\Programs\4.1\561\win_32-pentium' CTCWRAPDIR = 'C:\Users\user\AppData\Local\Temp\ctc' SHELL = '/bin/bash' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 42 Stepping 7, GenuineIntel' WINDIR = 'C:\Windows' ArchivePath = 'c:\Program Files\archive' PUBLIC = 'C:\Users\Public' ISSM_ARM_CORTEXDLL = 'C:\Program Files\ARM\ISSModel\Cortex\4.0\18\win_32-pentium' OLDPWD = '/cygdrive/c/cygwin' ARMCC41_CCOPT = '--licretry' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' windows_tracing_flags = '3' ARMCONF = 'C:\Program Files\ARM\RDI\armperip\1.3\50;C:\Program Files\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium;C:\Program Files\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Program Files\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium' temp = 'C:\Users\user\AppData\Local\Temp' VS90COMNTOOLS = 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\' OSVersion = 'Windows 7 Enterprise (x86)' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' TMP = '/tmp' RVDEBUG_SDK = 'C:\Program Files\ARM\RVD\Core\4.1.1\25\win_32-pentium\sdk' USERNAME = 'user' PROCESSOR_LEVEL = '6' ARMCC41_ASMOPT = '--licretry' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' RVD_FLASH_BASE = 'C:\Program Files\ARM\RVD\Flash\4.0\18\all\flash' HLPPATH = 'C:\Program Files\ARM\Documentation\RVD\4.1\11\onlinehelp' LANG = 'en_US.UTF-8' USERPROFILE = 'C:\Users\user' TZ = 'Europe/Berlin' ARMCC41INC = 'C:\Program Files\ARM\RVCT\Data\4.1\561\include\windows' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' PROCESSOR_ARCHITECTURE = 'x86' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' ARMDLL = 'C:\Program Files\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium;C:\Program Files\ARM\RDI\rdimsvr\1.3.1\129\win_32-pentium;C:\Program Files\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Program Files\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium' HOMEDRIVE = 'U:' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' ARMCC41_LINKOPT = '--licretry' PRINTER = '\\foo.bar' PROCESSOR_REVISION = '2a07' VS100COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\' ARM_PROFILER_RTSM_PATH = 'C:\Program Files\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' RVDEBUG_INSTALL = 'C:\Program Files\ARM\RVD\Core\4.1.1\25\win_32-pentium' RVDEBUG_HLPPATH = 'C:\Program Files\ARM\Documentation\RVD\4.1\11\onlinehelp' PROGRAMFILES = 'C:\Program Files' ARMROOT = 'C:\Program Files\ARM' NUMBER_OF_PROCESSORS = '4' ARM_RTSM_PATH = 'C:\Program Files\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release' FM_TRACE_PLUGINS = 'C:\Program Files\ARM\RVDS\ProfilerPlugIn\2.1\3\plugins\Win32_VC2005\FMProfilerPlugin.dll' SESSIONNAME = 'Console' ARM_RVI_TOOLS = 'C:\Program Files\ARM\RVI\Tools\4.1\32\programs\win_32-pentium' _ = '/usr/bin/cygcheck.exe' HKEY_CUR
Re: Cygwin and x: directory
On Jul 15 12:00, Adam Dinwoodie wrote: > On 15 July 2013 11:40, Corinna Vinschen wrote: > > On Jul 12 20:09, Nellis, Kenneth wrote: > >> IMHO, this makes an interesting problem (unrelated to git): > >> Shell script prompts user for file name. > >> User enters "x:". > >> Script proceeds as follows: > >> $ mkdir tmpdir > >> $ touch tmpdir/x: > >> $ # useful work done here > >> $ rm -r tmpdir > >> rm: cannot remove `tmpdir/x:': No such file or directory > >> rm: cannot remove `tmpdir': Directory not empty > >> $ > > > > That's a problem of how recursive rm works. It chdir's into > > the subdirs it's working on and then calls "x:" which is recognized > > as drive prefix of a windows path. `rm ./x:' works as expected. > > Does that mean this is a bug in Cygwin rm that ought to be fixed > (subject to SHTDI), or that it's a limitation of Cygwin rm for which > the cure looks to be worse than the symptoms? It's a limitation in Cygwin itself. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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 and x: directory
On 15 July 2013 11:40, Corinna Vinschen wrote: > On Jul 12 20:09, Nellis, Kenneth wrote: >> IMHO, this makes an interesting problem (unrelated to git): >> Shell script prompts user for file name. >> User enters "x:". >> Script proceeds as follows: >> $ mkdir tmpdir >> $ touch tmpdir/x: >> $ # useful work done here >> $ rm -r tmpdir >> rm: cannot remove `tmpdir/x:': No such file or directory >> rm: cannot remove `tmpdir': Directory not empty >> $ > > That's a problem of how recursive rm works. It chdir's into > the subdirs it's working on and then calls "x:" which is recognized > as drive prefix of a windows path. `rm ./x:' works as expected. Does that mean this is a bug in Cygwin rm that ought to be fixed (subject to SHTDI), or that it's a limitation of Cygwin rm for which the cure looks to be worse than the symptoms? -- 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 and x: directory
On Jul 12 20:09, Nellis, Kenneth wrote: > On 07/12/2013 08:42 AM, Mikko Rapeli wrote: > > > > Hi Cygwin and git developers, > > > > Does following scenario show signs of bugs in Cygwin and/or git? > > > > # setup git repo > > $ cd /tmp > > $ mkdir foo && cd foo > > $ git init > > > > # create x: directory > > $ mkdir x: > > $ ls > > x: > > IMHO, this makes an interesting problem (unrelated to git): > Shell script prompts user for file name. > User enters "x:". > Script proceeds as follows: > $ mkdir tmpdir > $ touch tmpdir/x: > $ # useful work done here > $ rm -r tmpdir > rm: cannot remove `tmpdir/x:': No such file or directory > rm: cannot remove `tmpdir': Directory not empty > $ That's a problem of how recursive rm works. It chdir's into the subdirs it's working on and then calls "x:" which is recognized as drive prefix of a windows path. `rm ./x:' works as expected. > It would seem that touch and rm are following different > rules regarding how files may be named. No. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Re: Native symlinks troubles
On Jul 14 14:32, LRN wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 17.06.2013 16:50, Corinna Vinschen wrote: > > On Jun 17 08:43, Алексей Павлов wrote: > >> This simple example illustrate problem with using native symlinks. > >> > >> $ export CYGWIN=winsymlinks:nativestrict > >> > >> $ mkdir bld && mkdir source && touch source/srcfile && ln -s > >> ../source/srcfile bld/bldfile > >> > >> $ ls -l bld > >> total 0 > >> lrwxrwxrwx 1 alexey None 10 Jun 17 08:29 bldfile -> ce/srcfile > > > > Thanks for the report. I applied a patch which should fix this issue. > > > > I'm just uploading a new developer snapshot 2013-06-17 to > > http://cygwin.com/snapshots/, as well as a new 64 bit Cygwin test > > release 1.7.21-4. Please give one of them a try. > > > > > > Thanks, > > Corinna > > > > Try this (with CYGWIN=winsymlinks:nativestrict): > $ mkdir zoo > $ touch zoo/foo > $ ln -s zoo/foo zoo.x > $ ls -l zoo.x > > expected result: > lrwxrwxrwx X AA BBB CC HH:MM zoo.x -> zoo/foo > > actual result: > lrwxrwxrwx X AA BBB CC HH:MM zoo.x -> foo > > happens at least when name (minus extension) of the symlink is the same > as the name of the first component (i.e. directory name) of the target. Thanks for the report. I applied a patch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
During postinstall, warning: Package: Unknown package; a2ps.sh exit code 2
Hi; Package: Unknown package a2ps.sh exit code 2 Is there a missing dependency? This is what happens when I run sh /etc/postinstall/a2ps.sh manually from mintty: $ sh -xv /etc/postinstall/a2ps.sh if [ ! -f /etc/a2ps-site.cfg ] then /usr/bin/mkdir -p /etc /usr/bin/cp /etc/defaults/etc/a2ps-site.cfg /etc/a2ps-site.cfg fi + '[' '!' -f /etc/a2ps-site.cfg ']' if [ ! -f /etc/a2ps.cfg ] then /usr/bin/mkdir -p /etc /usr/bin/cp /etc/defaults/etc/a2ps.cfg /etc/a2ps.cfg fi + '[' '!' -f /etc/a2ps.cfg ']' cd /usr/share/a2ps/afm + cd /usr/share/a2ps/afm ./make_fonts_map.sh && /bin/mv -f fonts.map.new fonts.map + ./make_fonts_map.sh Looking for the afm files read by a2ps... a2ps: unknown medium `libpaper' Extracting font names... Sorting entries... sort: open failed: fonts.map.new: No such file or directory Thanks, Ken Wolcott -- 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: SVN::Ra problems
With latest cygwin packages, including subversion 1.8, perl -e 'require SVN::Ra' works, but svn 1.8 breaks HTTPS NTML authentication which works with 1.7.10. Downgrading to subversion 1.7.10 worked well a few weeks back but not anymore. Would be nice to figure out what changed. -Mikko -- 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: SVN::Ra problems
> SVN/_Ra/_Ra.dll is part of the subversion-perl package, as is > SVN/Base.pm. You have one but not the other. Do you have There is a _Ra.dll and a Base.pm, files are there. > /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/SVN/_Ra/_Ra.dll.new? > If so, you have to reboot your computer. Reboots done too many times. Cygwin reinstalled too. Forgot to mention that subversion is downgraded to 1.7.10 since HTTPS authentication is broken with 1.8. Few days ago on an older cygwin installation everything was working just fine (until an 'rm -rf C:' happened with git, another story). cygcheck reports this: Cygwin Configuration Diagnostics Current System Time: Mon Jul 15 09:21:58 2013 Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: C:\Apps\ARM\bin\win_32-pentium C:\Testwell\CTC c:\Oracle\Client64\bin\ C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ c:\Program Files (x86)\Microsoft Application Virtualization Client C:\Apps\cygwin\bin C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium\bin C:\Apps\ARM\Utilities\FLEXlm\10.8.5.0\1\win_32-pentium C:\Apps\ARM\RVCT\Programs\4.1\561\win_32-pentium C:\Apps\ARM\RVI\Tools\4.1\32\programs\win_32-pentium C:\Program Files\TortoiseSVN\bin C:\Program Files (x86)\Subversion\bin C:\Apps\apache-ant\bin C:\Apps\Python27 Output from C:\Apps\cygwin\bin\id.exe UID: 805092(user) GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows PWD = '/' HOME = '/home/user' HOMEPATH = '\' APPDATA = 'C:\Users\user\AppData\Roaming' ProgramW6432 = 'C:\Program Files' ARMCC41LIB = 'C:\Apps\ARM\RVCT\Data\4.1\561\lib' ARM_ENABLED_PRODUCTS = 'C:\Apps\ARM|RVDS/Contents/4.1/158:platform=win_32-pentium,extras_dir=professional\,encryption=none,regime=rel,capability=professional' ARMCC41BIN = 'C:\Apps\ARM\RVCT\Programs\4.1\561\win_32-pentium' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 26 Stepping 5, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' ISSM_ARM_CORTEXDLL = 'C:\Apps\ARM\ISSModel\Cortex\4.0\18\win_32-pentium' USERDOMAIN = 'MUC' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' UATDATA = 'C:\Windows\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' windows_tracing_flags = '3' ARMCONF = 'C:\Apps\ARM\RDI\armperip\1.3\50;C:\Apps\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium;C:\Apps\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Apps\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\' TEMP = '/cygdrive/c/Users/user/AppData/Local/Temp' OSVersion = 'Windows 7 Enterprise (x64)' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' RVDEBUG_SDK = 'C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium\sdk' MasterImageVer = 'x64-5.12' USERNAME = 'user' ARMLMD_LICENSE_FILE = 'foo.bar' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' RVD_FLASH_BASE = 'C:\Apps\ARM\RVD\Flash\4.0\18\all\flash' PROCESSOR_ARCHITEW6432 = 'AMD64' HLPPATH = 'C:\Apps\ARM\Documentation\RVD\4.1\11\onlinehelp' USERPROFILE = 'C:\Users\user' ARMCC41INC = 'C:\Apps\ARM\RVCT\Data\4.1\561\include\windows' LOGONSERVER = '\\HEU0MUC07' CTCHOME = 'C:\Testwell\CTC' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\user\AppData\Local' ProgramData = 'C:\ProgramData' SHLVL = '1' USERDNSDOMAIN = 'COMPANY.CORP' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' ARMDLL = 'C:\Apps\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium;C:\Apps\ARM\RDI\rdimsvr\1.3.1\129\win_32-pentium;C:\Apps\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Apps\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium' HOMEDRIVE = 'U:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/cygdrive/c/Users/user/AppData/Local/Temp' SYSTEMROOT = 'C:\Windows' PROCESSOR_REVISION = '1a05' VS100COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\' ARM_PROFILER_RTSM_PATH = 'C:\Apps\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release' RVDEBUG_INSTALL = 'C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium' RVDEBUG_HLPPATH = 'C:\Apps\ARM\Documentation\RVD\4.1\11\onlinehelp' PROGRAMFILES = 'C:\Program Files (x86)' HOMESHARE = '\\foo.bar\user' ARMROOT = 'C:\Apps\ARM' NUMBER_OF_PROCESSORS = '4' ARM_RTSM_PATH = 'C:\Apps\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release' FM_TRACE_PLUGINS = 'C:\Apps\ARM\RVDS\ProfilerPlugIn\2.1\3\plugins\Win32_VC2005\FMProfilerPl
