Problem running top on Windows 7
See attached stackdump. This output was followed by a bundle of messages like this: End of stack trace 7247 [sig] top 6112 exception::handle: Error while dumping state (probably corrupted stack) 128235 [sig] top 6112 exception::handle: Error while dumping state (probably corrupted stack) 221305 [sig] top 6112 exception::handle: Error while dumping state (probably corrupted stack) Is there other diagnostics needed? cygcheck -c returns OK for all packages. The top session runs for several minutes fine before this fault occurs. Jerry je...@quasar ~ $ bin/ gcc/ prs/ top.exe.stackdump* je...@quasar ~ $ Stack trace: Frame Function Args 0028B734 76771184 (0288, EA60, , 0028B858) 0028B748 76771138 (0288, EA60, 00A4, 0028B83C) 0028B858 610C6013 (, 0288, 0028B878, ) 0028B938 610C2CA7 (, , , ) 0028B988 610C30BB (17E0, 0028B9B0, 0028BBF0, 0028BBC0) 0028BA48 610C31E1 (17E0, 0006, 0028BA78, 610C3285) 0028BA58 610C321C (0006, 0028CE80, 4004, 610F3943) 0028BA78 610C3285 (, , 00D9F6B8, C004) Exception: STATUS_ACCESS_VIOLATION at eip=61026397 eax=610F163D ebx=61163240 ecx=C010 edx=C014 esi=0008 edi=18F4CC80 ebp=18F4C8E8 esp=18F4C8E0 program=C:\cygwin\bin\top.exe, pid 6112, thread sig cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 18F4C8E8 61026397 (61163240, 611A3B45, C004, ) 18F4C908 6102736C (0028B71C, 0001, 0001, ) 18F4C938 61027EA5 (0050, 18F4C974, , ) 18F4CC58 610284CC (0118, 18F4CC80, 00A4, 18F4CD28) 18F4CD38 610C6C1B (61162220, , , ) 18F4CD68 61003DC1 (, , , 61004654) End of stack trace -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN_NT-6.1-WOW64: Unable to install rubies with rvm
Jon Seidel CMC edpci.com> writes: > > When I try to compile a ruby (1.8.7 or 1.9.2) using rvm on cygwin, I get the > following errors. I can't find any similar issues either on the RVM list or > the cygwin list. As noted elsewhere on ruby-lang.org, I did try to install > 1.8.7 first (1.9.2 requires ruby to already be installed). FWIW: I have > installed RVM and both these rubies on a Mac and that worked just fine. > > I hope someone has run into this already and has a work-around/suggestion. > > Thanks...jon > Version 1.8.7 installation attempt > $ rvm install 1.8.7-head > /cygdrive/c/home/jes/.rvm/rubies/ruby-1.8.7-head, this may take a while > depending on your cpu(s)... > > ruby-1.9.2-head - #fetching > Updating ruby from http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_7 > Copying from repo to src path... > Running autoconf > ruby-1.8.7-head - #configuring > ruby-1.8.7-head - #compiling > Error running 'make ', please check > /cygdrive/c/home/jes/.rvm/log/ruby-1.8.7-head/make.error.log > There has been an error while running make. Halting the installation. > $less /cygdrive/c/home/jes/.rvm/log/ruby-1.8.7-head/make.error.log > [2010-11-16 09:37:58] make > eval.c:211: error: conflicting types for '_longjmp' > /usr/include/machine/setjmp.h:335: error: previous declaration of '_longjmp' > was here > eval.c:211: error: conflicting types for '_longjmp' I have the same issue. Although I did manage to get ruby 1.9.2 installed, 1.8.7 died with the same errors you have. I also have both rubies working under rvm on my Mac without this issue. My rvm version on cygwin is: $ rvm -v rvm 1.1.0 Did you ever manage to get ruby 1.8.7 installed in the end? - Sean -- 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
Your Rental Property Listing
Hi! I noticed your property website online and I thought you might be interested in my new rental website called JoeOptions: http://www.joeoptions.com/ Here's how JoeOptions benefits you: * FREE listings through December 31, 2011 for properties created on JoeOptions. * UNLIMITED pictures/videos/links to help promote and better represent your Property and the Destination. * HomeAway Connect integration eliminating the need to manage multiple calendars * Unique property management tool allowing Renters to find your property based on Date, Price and Location in one step. * Meet People Where They Are: Social Media integration with Facebook, Twitter, YouTube, etc. Check out this video that explains why JoeOptions: http://www.youtube.com/watch?v=kohBjcuPMhE We look forward to you joining us at JoeOptions! Best Regards, Joe We've sent you this email because we think you'll enjoy using JoeOptions. If you'd rather not receive any more emails from us, please email unsubscr...@joeoptions.com, and we'll take you off our list. To remove your email from the "20101123" mailing list, click here: http://cs.joeoptions.com/index.php?ACT=5&id=WAYkSaB8q1 -- 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: cygpath unable to translate the *nix path to an NTFS junction point
On Wed, Nov 24, 2010 at 12:09 PM, Andrey Repin wrote:
> Greetings, Pierce Morton!
>
> This is expected behavior for cross-links.
I took a look at the behaviour of cygpath when using cygwin symlinks
and I understand now why it does what it does with junction points.
Consistency between the two seems reasonable if that was its existing
behaviour before junction support was added.
However, the behaviour of cygpath is not entirely consistent between
junctions and symlinks.
Let's say you have the structure
c:\example\targ
c:\example\targ\subfolder
c:\example\junc
c:\example\sym
where targ and its child are real folders, junc is junction point
leading to targ, and sym is a cygwin symlink leading to targ.
cd /cygpath/c/example
cygpath -w -a junc
cygpath -w -a sym
both cygpath calls produce
c:\example\targ
The same happens with calls like
cygpath -w /cygdrive/c/example/junc
cygpath -w /cygdrive/c/example/sym
Go inside the subfolder via the junction point:
cd /cygdrive/c/example/junc/subfolder
and call cygpath again to find the absolute path:
cygpath -w -a .
and you're given:
c:\example\junc\subfolder
Try this with the symlink however:
cd /cygdrive/c/example/sym/subfolder
cygpath -w -a .
and you'll get
c:\example\targ\subfolder
One uses the dereferenced path, and one uses the symbolic path.
> However, the real reparse points mounting different volumes...
>
> [C:\]$ uname -a
> CYGWIN_NT-5.1 daemon2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> [C:\]$ dir C:\ | grep arc
> 2010-11-22 12:16 arc
>
> [C:\]$ cygpath -w /c/arc
> C:\arc
>
> Real junction target: \\?\Volume{4aee6480-972b-11de-b8ca-0015f2ef1bb5}\arc
>
That's interesting, but I'm not doing anything as complex as linking
across volumes.
In your case ... perhaps cygpath should attempt to match volume names
to see whether that volume has a real drive letter, then substitute
into the generated path as necessary?
>> This leaves cygpath completely unable to translate the original path
>> of an NTFS junction. This is proving to be a problem for me (I'm
>> trying to use the output of cygpath for the equivalent of a backtick
>> operation in another script...)
>
>> I haven't taken a look at the C source yet, so I'm not sure whether
>> this problem lies in cygpath itself or the cygwin API layer.
>
> Say, it's a missing feature.
>
> @Corinna: Any chance cygpath get a --nofollow switch or something?
+1 for --nofollow
The reason I need this is because I need certain Windows apps to treat
the junction point in a transparent fashion, similarly to how most nix
apps treat symlinks. I want to pass the translated path to a Windows
app so that it can work with that path without ever being aware of
when the junction point in the path changes to point to something
else. The app needs to think C:\example\junc\importantfile.blah is
located in the same place when it could be a different file in a
different directory any day via the junction.
I also want to be able to target the junction point itself (so I can
deal with it using junction tools such as Junction from Sysinternals
or mklink etc). Right now I can't pass the untranslated address of
the junction to anything.
This would be solved by giving cygpath the option to do a nofollow translate.
Apologies if this message ends up somewhere strange - I've never
really used a old-school mailing list like this before.
--
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: Python: subprocess running rsync causes broken socket in telnetlib
On Wed, Nov 17, 2010 at 09:57, David Sastre wrote: > On Wed, Nov 17, 2010 at 09:39:38AM +1300, David Antliff wrote: >> On Mon, Nov 15, 2010 at 10:00, David Antliff wrote: >> > Can anyone else see the fault if they run the script I posted? [snip] > > I can reproduce it on my side. That doesn't mean I can debug it > further, though, sorry. Thanks for giving it a try. Cygwin core developers - is there anything more I can do to help solve this one? Perhaps it's related to other unexplained process interaction? It's certainly a disturbing thing to see. -- 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: Updated: guile-1.8.7
On Tue, Nov 23, 2010 at 09:06:44PM -0500, Mark Harig wrote: On Mon, Nov 22, 2010 at 11:10:39AM +0100, Jan Nieuwenhuizen wrote: > I've updated the version of Guile to 1.8.7. This also includes the > guile-devel packages. > > This is a new upstream release. For a full update of changes, see > the file usr/share/doc/guile/NEWS in the guile-doc package. > > Cygwin-specific changes > > * New upstream release. > * Add int scm_i_terminating export, thanks Yaakov. > * Move to gub3: http://lilypond.org/gub . > > > == > I have installed guile 1.8.7, guile-doc 1.8.7, and libguile17 1.8.7, along with cygwin 1.7.7: $ cygcheck -c cygwin guile guile-doc libguile17 Cygwin Package Information Package VersionStatus cygwin 1.7.7-1OK guile1.8.7-1OK guile-doc1.8.7-1OK libguile17 1.8.7-1OK I have previously been able to install and start guile 1.8.2 without error, but when I attempt to start guile 1.8.7, it fails immediately with a Stack overflow error: 1. Here is a check of the other packages that guile requires at run-time: $ cygcheck -c crypt gmp libltdl3 Cygwin Package Information Package VersionStatus crypt1.1-1 OK gmp 4.3.1-3OK libltdl3 1.5.27a-1 OK $ cygcheck -c libintl2 libintl3 libintl8 Cygwin Package Information Package VersionStatus libintl2 0.12.1-3 OK libintl3 0.14.5-1 OK libintl8 0.17-11OK 2. Another problem is that guile-doc 1.8.7, unlike guile-doc 1.8.2, does not include the 'info' documentation files: $ cygcheck -l guile-doc /usr/share/doc/guile/GUILE-VERSION /usr/share/doc/guile/LIBGUILEREADLINE-VERSION /usr/share/doc/guile/PROGRAM /usr/share/doc/guile/ChangeLog-2008 /usr/share/doc/guile/NEWS /usr/share/doc/guile/LICENSE /usr/share/doc/guile/ChangeLog /usr/share/doc/guile/ChangeLog-gh /usr/share/doc/guile/COPYING.LESSER /usr/share/doc/guile/THANKS /usr/share/doc/guile/ChangeLog-2000 /usr/share/doc/guile/README /usr/share/doc/guile/AUTHORS /usr/share/doc/guile/HACKING /usr/share/doc/guile/ChangeLog-scm /usr/share/doc/guile/INSTALL /usr/share/doc/guile/ABOUT-NLS /usr/share/doc/guile/ChangeLog-1996-1999 /usr/share/doc/guile/ChangeLog-threads -- 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: Updated: guile-1.8.7
On Mon, Nov 22, 2010 at 11:10:39AM +0100, Jan Nieuwenhuizen wrote: > I've updated the version of Guile to 1.8.7. This also includes the > guile-devel packages. > > This is a new upstream release. For a full update of changes, see > the file usr/share/doc/guile/NEWS in the guile-doc package. > > Cygwin-specific changes > > * New upstream release. > * Add int scm_i_terminating export, thanks Yaakov. > * Move to gub3: http://lilypond.org/gub . > > > == > I have installed guile 1.8.7, guile-doc 1.8.7, and libguile17 1.8.7, along with cygwin 1.7.7: $ cygcheck -c cygwin guile guile-doc libguile17 Cygwin Package Information Package VersionStatus cygwin 1.7.7-1OK guile1.8.7-1OK guile-doc1.8.7-1OK libguile17 1.8.7-1OK I have previously been able to install and start guile 1.8.2 without error, but when I attempt to start guile 1.8.7, it fails immediately with a Stack overflow error: $ guile -q --debug -- Backtrace: In unknown file: ?: 129* [#] ?: 130* (let* ((file #)) (cond (# => #) (# => #))) ?: 131 [# "/usr/share/guile/1.8/ice-9/debug.scm"] ?: 132 [with-fluid* # #f #] ?: 133* [#] ?: 134* [load-file # ...] ?: 135* [save-module-excursion #] ?: 136 (let (# #) (dynamic-wind # thunk #)) ?: 137 [dynamic-wind # # #] ?: 138* [#] ?: 139* [primitive-load "/usr/share/guile/1.8/ice-9/debug.scm"] In /usr/share/guile/1.8/ice-9/debug.scm: 22: 140* (define-module (ice-9 debug) :export ...) In unknown file: ?: 141* [copy-tree ... ?: 142* [apply # (# :export #)] ?: 143 [# (ice-9 debug) :export ...] ?: 144 (quasiquote (eval-case (# #) (else #))) ?: 145* [compile-define-module-args (# :export #)] ?: 146 ((letrec ((loop #)) loop) (quasiquote ((quote #))) (cdr args)) ?: 147* (letrec ((loop (lambda # #))) loop) ?: 148* (lambda (compiled-args args) (cond (# #) (# #) (# #) ...)) : In expression (lambda (compiled-args args) (cond # # ...)): : Stack overflow --- End of stack dump --- This error is repeatable (the same error messages with the same line numbers). The same error occurs if guile is provided no command-line options. I can un-install version 1.8.7, install version 1.8.2, and start guile without error. Please let me know if there is some information that I can provide that would help to diagnose the source of this problem. Here are sha1sums of the files that I have downloaded and installed: $ sha1sum.exe guile-1.8.7-1.tar.bz2 ee5cdc729998bfd7c8aa93c9e53467d28c77153b *guile-1.8.7-1.tar.bz2 $ sha1sum.exe libguile17-1.8.7-1.tar.bz2 cb35fa72ad8fe46a27abfc2bd3d38f731cb127e5 *libguile17-1.8.7-1.tar.bz2 $ sha1sum.exe guile-doc-1.8.7-1.tar.bz2 2e42accc2103f7ee83808b91319bf43611004a36 *guile-doc-1.8.7-1.tar.bz2 $ sha1sum cygwin-1.7.7-1.tar.bz2 61d32c981e6aa1d19b8586d1f9f6c19d87b06bf2 *cygwin-1.7.7-1.tar.bz2 -- 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: cygpath unable to translate the *nix path to an NTFS junction point
Greetings, Pierce Morton!
> I've recently installed cygwin using the web installer, and have found
> an error in the way that cygpath translates junction point paths from
> *nix to Windows paths when dealing with a junction point.
> If you've got a junction point (let's call it JUNC, located at
> c:\example\junc ) and a real folder TARG (located at c:\example\TARG )
> and your junction point points to TARG:
> cygpath -w /cygdrive/c/example/junc
> will give you
> c:\example\TARG
> as your output instead.
This is expected behavior for cross-links.
However, the real reparse points mounting different volumes...
[C:\]$ uname -a
CYGWIN_NT-5.1 daemon2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
[C:\]$ dir C:\ | grep arc
2010-11-22 12:16arc
[C:\]$ cygpath -w /c/arc
C:\arc
Real junction target: \\?\Volume{4aee6480-972b-11de-b8ca-0015f2ef1bb5}\arc
> This leaves cygpath completely unable to translate the original path
> of an NTFS junction. This is proving to be a problem for me (I'm
> trying to use the output of cygpath for the equivalent of a backtick
> operation in another script...)
> I haven't taken a look at the C source yet, so I'm not sure whether
> this problem lies in cygpath itself or the cygwin API layer.
Say, it's a missing feature.
@Corinna: Any chance cygpath get a --nofollow switch or something?
--
WBR,
Andrey Repin (anrdae...@freemail.ru) 24.11.2010, <3:48>
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: ioctl() on socket fd's take 3 seconds on 1.7.7
On 23/11/2010 16:38, Corinna Vinschen wrote: On Nov 23 14:10, Jason Curl wrote: Actually, after reading a bit about this flag, the usage in Cygwin seems to be wrong anyway. I applied a patch so that IFF_NOARP is only set for PPP and SLIP devices, so the call to SendARP is gone. Please test CVS or the next developer snapshot. I tried to understand what this flag is for. As far as I can understand, windows will always reply to ARP requests. There's a registry entry for "gratuitous arp". So doesn't that imply IFF_NOARP will be set for all interfaces? I downloaded the snapshot as of today. The 3 second delays are no longer present (thanks!). Best Regards, Jason. -- 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: 1.7.8: files exist but can not be read
I tested the snapshot, and the problem appears to be fixed. Thanks! Teun Op 23-11-2010 10:39, Corinna Vinschen schreef: Please don't http://cygwin.com/acronyms/#TOFU. Thank you. On Nov 22 19:11, A.R. Burgers wrote: Hi, here the script file.sh and its output results.txt, pasted in the mail, including the output of the ntqueryfile program. I ran ntqueryfile both on a netapp file and on a local file. hope this helps [...] *** ./ntqueryfile nas01\\g_zon_software\$\\cygwin17\\text.txt: NtQueryInformationFile(FNOI): 0xc00d fsi.AllocationSize 64 fsi.EndOfFile 7 Yes, it helps. It confirms my suspicion that Netapps don't grok the FileNetworkOpenInformation info class. I'm wondering what else is not fully implemented on these drives. That's the forth problem we have to workaround for these thingies. Sigh. I applied a patch which should fix this problem. Please test the latest from CVS or the next developer snapshot from http://cygwin.com/snapshots/ Thanks, Corinna -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
On Nov 23 14:10, Jason Curl wrote: > Corinna Vinschen cygwin.com> writes: > > On Nov 22 21:29, Jason Curl wrote: > > > The actual delays are caused by SendARP() called from get_xp_ifs(). > > > Interestingly enough, it isn't always slow, only sometimes. > > > [...] > > Ok, so SendARP is kind of a problematic call. As you can see from the > > source code, it's only called to set the IFF_NOARP flag. Probably > > that's a bit over the top. What about just disabling this code? > > I'll try this out on my next opportunity. I personally have no need for > IFF_NOARP. Actually, after reading a bit about this flag, the usage in Cygwin seems to be wrong anyway. I applied a patch so that IFF_NOARP is only set for PPP and SLIP devices, so the call to SendARP is gone. Please test CVS or the next developer snapshot. Thanks, Corinna -- 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: File format problem after updatin to 1.7.1 - solved
On Fri, Nov 19, 2010 at 02:47:43PM -0600, Jeremy Bopp wrote: >...I referred to the official source of information in the hopes that >the list archives would not be polluted with contradictory information >if those details ever change again. For the record, I thank you for exercising this insight. As the mailing list archives grow ever larger, we'll certain to have contradictory advice there so you're absolutely right to point people at the documentation since we do endeavor to keep it accurate. cgf -- 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: WG: Windows Environment Variables
On 2010-11-23 13:25Z, rudolf.be...@xxx.de wrote: > > When login via ssh to a Cygwin Server I only get System Variables, like > TEMP or TMP. I'm missing variables that are defined in the registries. > Like %Programfiles% or %COMMONPROGRAMFILES% Security rationale: http://cygwin.com/ml/cygwin/2010-05/msg00311.html Suggested workaround: http://cygwin.com/ml/cygwin/2010-05/msg00012.html -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
Corinna Vinschen cygwin.com> writes: > > On Nov 22 21:29, Jason Curl wrote: > > The actual delays are caused by SendARP() called from get_xp_ifs(). > > Interestingly enough, it isn't always slow, only sometimes. > > [...] > > First of all, thanks for looking deeper into this. Thanks for taking notice for my initial problem. > This autoconfig address is returned by GetAdapterAddresses so it has > been configured at one point, even if the interface is not visible. > > Ok, so SendARP is kind of a problematic call. As you can see from the > source code, it's only called to set the IFF_NOARP flag. Probably > that's a bit over the top. What about just disabling this code? I'll try this out on my next opportunity. I personally have no need for IFF_NOARP. Jason. -- 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
WG: Windows Environment Variables
Hello, I have a problem with Cygwin 1.7.7 and Windows Environment Variables. When login via ssh to a Cygwin Server I only get System Variables, like TEMP or TMP. I'm missing variables that are defined in the registries. Like %Programfiles% or %COMMONPROGRAMFILES% We need this variables because we have some Perl Scripts running that uses this variables. Using the bash.bashrc does not help, because there is ni login procedure. It works fine on a Cygwin Server 1.7.1 $ set ALLUSERSPROFILE='C:\ProgramData' BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="2" [2]="51" [3]="24" [4]="release" [5]="i686-pc-cy in") BASH_VERSION='3.2.51(24)-release' COMMONPROGRAMFILES='C:\Program Files (x86)\Common Files' COMPUTERNAME=D25H1002 COMSPEC='C:\Windows\system32\cmd.exe' CVS_RSH=/bin/ssh CYGWIN=nodosfilewarning DIRSTACK=() EUID=99010 GROUPS=() HISTFILE=/home/a00bend/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/a00bend HOMEDRIVE=E: HOMEPATH='\sshprofiles\a00bend' HOSTNAME= HOSTTYPE=i686 IFS=$' \t\n' INFOPATH=/usr/local/info:/usr/share/info:/usr/info: LANG=C.UTF-8 LOGNAME=a00bend LOGONSERVER='\\D25D1002' MACHTYPE=i686-pc-cygwin MAIL=/var/spool/mail/a00bend MAILCHECK=60 MANPATH=/usr/local/man:/usr/share/man:/usr/man: OLDPWD=/home/a00bend OPTERR=1 OPTIND=1 OS=Windows_NT OSTYPE=cygwin PATH='/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Perl/site/bin:/cygdrive/c/Perl/ n:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System3 Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/cygdrive/c/sdvadmin 2k3tools:/cygdrive/c/Program Files (x86)/ASDIS/tools/:/cygdrive/c/Program File (x86)/ASDIS/Client/:/usr/bin:/cygdrive/c/Program Files (x86)/PHP/5.2.12:/bin' PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' PIPESTATUS=([0]="0") PPID=588 PRINTER='Microsoft XPS Document Writer' PS1='\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' PS2='> ' PS4='+ ' PWD=/home/a00bend SHELL=/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:mo tor SHLVL=1 SSH_CLIENT='10.2.10.163 3851 22' SSH_CONNECTION='10.2.10.163 3851 10.38.2.88 22' SSH_TTY=/dev/tty0 SYSTEMDRIVE=C: SYSTEMROOT='C:\Windows' TERM=cygwin UID=99010 USER=a00bend USERDOMAIN=SDVRZ USERNAME=a00bend USERPROFILE='C:\Users\a00bend' WINDIR='C:\Windows' _=/etc/bash.bashrc f= $ Any ideas? Regards Rudolf -- 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: lilypond-2.13.39
I've updated the version of LilyPond to 2.13.39. This is the first beta release for the upcoming 2.14 stable series. User comments and suggestions are welcomed, see http://lilypond.org/contact . This is a new upstream release. For a full update of changes, please see http://lilypond.org/doc/v2.13/Documentation/changes/ === To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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 the above URL. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
On Nov 22 21:29, Jason Curl wrote: > The actual delays are caused by SendARP() called from get_xp_ifs(). > Interestingly enough, it isn't always slow, only sometimes. > [...] First of all, thanks for looking deeper into this. > And the interface that is failing: D4B7FEA9 = 169.254.183.212 > doesn't appear by a call to "ipconfig /all". I'm guessing that > Windows is actually making a network request for this non-existent > interface. > > ./Windows/v5.0/Include/WinError.h:#define ERROR_BAD_NET_NAME67L > > ERROR_BAD_NET_NAME > "The network name cannot be found. This error is returned on Windows > Vista and later when an ARP reply to the SendARP request was not > received. This error occurs if the destination IPv4 address could > not be reached." > > I'm not sure where this IP is currently coming from... This autoconfig address is returned by GetAdapterAddresses so it has been configured at one point, even if the interface is not visible. Ok, so SendARP is kind of a problematic call. As you can see from the source code, it's only called to set the IFF_NOARP flag. Probably that's a bit over the top. What about just disabling this code? Corinna -- 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: cygpath unable to translate the *nix path to an NTFS junction point
On Nov 23 12:34, Pierce Morton wrote: > If you've got a junction point (let's call it JUNC, located at > c:\example\junc ) and a real folder TARG (located at c:\example\TARG ) > and your junction point points to TARG: > cygpath -w /cygdrive/c/example/junc > will give you > c:\example\TARG > as your output instead. > > This leaves cygpath completely unable to translate the original path > of an NTFS junction. This is proving to be a problem for me (I'm > trying to use the output of cygpath for the equivalent of a backtick > operation in another script...) Sorry if I don't get your problem. The resulting path is correct, isn't it? Cygwin handles junction points as symlinks. When creating a Windows path, symlinks get resolved, since native Windows applications (the target audience for cygpath -w) don't understand symlinks. > However, the reverse (win to nix) works fine: > cygpath "c:\example\junc" > gives you > /cygdrive/c/example/junc > without the faulty translation. "Faulty" is a bit harsh, isn't it? The target audience for `cygpath -u' are POSIX apps which *do* understand symlinks, so it's not necessary to resolve them. > Interestingly enough, cygpath does not normally seem to care whether > or not a folder really exists. > cygpath -w /cygdrive/c/thisdirisnotreal/blah > will give you > c:\thisdirisnotreal\blah > even if "thisdirisnotreal" doesn't exist in the filesystem. Sure. Otherwise it's not possible to create DOS paths from POSIX paths for yet-to-be-created files. Corinna -- 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: 1.7.8: files exist but can not be read
Please don't http://cygwin.com/acronyms/#TOFU. Thank you. On Nov 22 19:11, A.R. Burgers wrote: > Hi, > > here the script file.sh and its output results.txt, > pasted in the mail, including the output of the ntqueryfile > program. I ran ntqueryfile both on a netapp file and on a local file. > > hope this helps > [...] > *** ./ntqueryfile nas01\\g_zon_software\$\\cygwin17\\text.txt: > NtQueryInformationFile(FNOI): 0xc00d > fsi.AllocationSize 64 > fsi.EndOfFile 7 Yes, it helps. It confirms my suspicion that Netapps don't grok the FileNetworkOpenInformation info class. I'm wondering what else is not fully implemented on these drives. That's the forth problem we have to workaround for these thingies. Sigh. I applied a patch which should fix this problem. Please test the latest from CVS or the next developer snapshot from http://cygwin.com/snapshots/ Thanks, Corinna -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
René Berber computer.org> writes:
>
> On 11/22/2010 2:29 PM, Jason Curl wrote:
> [snip]
> > And the interface that is failing: D4B7FEA9 = 169.254.183.212 doesn't
> > appear by a call to "ipconfig /all". I'm guessing that Windows is
> [snip]
> > I'm not sure where this IP is currently coming from...
>
> It's Microsoft's default address, used when the network interface is set
> to "Obtain an IP address automatically" and no server responds or
> accepts the request, and the "Alternate Configuration" is set to use
> "Automatic private IP address".
>
> But the real point is: it shouldn't be used in any case other than when
> the interface can't get an address. And that is only during
> configuration...
Your second point is not relevant, it doesn't matter if my interface is fixed,
DHCP or AutoIP, so long as the Windows routing table knows what IP address
belongs with which MAC. Proof is in the logs.
There are two instances of AutoIP. The second instance (VMware Network Adapter
VMnet1) is bound to an interface with 169.254.211.193. The problematic instance
169.254.183.212 isn't listed in "ipconfig".
So the question can be, where does 169.254.183.212 which doesn't appear to be
bound to a particular interface, so that when SendARP() is called, Win7 thinks
it needs to send a query out on the network thus causing a 3 second delay?
I didn't get enough time to get this far last night. It appears to be a problem
with "Tunnel adapter isatap.{A045DC0F-A979-49B3-954C-D0678365FF26}". But I have
a feeling it's probably to do with my Bluetooth Interface (as other tunnel
adapters don't cause problems).
{4ED54D4E-1024-4BDF-A926-67D2895D2DC4} a9fe0202
{A045DC0F-A979-49B3-954C-D0678365FF26} a9feb7d4 <- Culprit
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} a9fe0202
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007}
{56D2E68A-4173-4117-A719-65123B973C65} c0a80119
{7E5203E8-97DE-4822-9A2E-380BD258D97E} a9fed3c1
{8424F604-4FAE-4541-9D8E-7B0A583A0956} c0a8df01
{846EE342-7039-11DE-9D20-806E6F6E6963} 7f01
The output of my "ifconf" replacement shows, where the MAC address of the
culprit is the same as the BT interface:
{4ED54D4E-1024-4BDF-A926-67D2895D2DC4} AF_INET 169.254.2.2
255.255.255.0
169.254.2.255169.254.2.2 80:00:60:0F:E8:00 yes no
{A045DC0F-A979-49B3-954C-D0678365FF26} AF_INET 169.254.183.212
255.255.0.0
169.254.255.255 169.254.183.212 00:60:57:1B:21:99 yes no
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} AF_INET 169.254.2.2
255.255.255.0
169.254.2.255169.254.2.2 80:00:60:0F:E8:00 yes no
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007} AF_INET 0.0.0.0
255.0.0.0
0.255.255.2550.0.0.0 00:60:57:1B:21:99 yes no
{56D2E68A-4173-4117-A719-65123B973C65} AF_INET 192.168.1.25
255.255.255.0
192.168.1.255192.168.1.25 00:24:1D:71:F6:EC yes yes
{7E5203E8-97DE-4822-9A2E-380BD258D97E} AF_INET 169.254.211.193
255.255.0.0
169.254.255.255 169.254.211.193 00:50:56:C0:00:01 yes yes
{8424F604-4FAE-4541-9D8E-7B0A583A0956} AF_INET 192.168.223.1
255.255.255.0
192.168.223.255 192.168.223.100:50:56:C0:00:08 yes yes
{846EE342-7039-11DE-9D20-806E6F6E6963} AF_INET 127.0.0.1
255.0.0.0
127.255.255.255 127.0.0.100:00:00:00:00:00 yes yes
In this case, it appears that this is an example of an interface that is
*not* up.
Thanks & Best Regards,
Jason.
--
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
