Re: weird problem with clnt_create() and EADDRINUSE
I didn't include the cygwin version info. I updated recently. I used the 64-bit installer. This problem has been happening for years. It's just worse recently. I used to be that it was very intermittent, but now I can't get through a complete test iteration (which is about 80 invocations of hammernfs.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
weird problem with clnt_create() and EADDRINUSE
I have a C program (attached) that I run to test a Windows NFS server
(built in Lisp, https://github.com/franzinc/nfs).
I can run this program on Linux and I've never had a problem with it.
On Windows, I randomly get errors like this:
./hammernfs.exe -i 3 -v 2 -t 60 -b 8192 -p tcp 127.0.0.1:/nfs.test/nfstestfile
clnt_create_with_retry: 13: clnt_create failed. rpc_createerr.cf_stat: 12,
rpc_createerr.cf_error.re_errno: 112
clnt_create_with_retry: Try #1: clnt_create: RPC: Remote system error - Address
already in use
clnt_create_with_retry: 13: clnt_create failed. rpc_createerr.cf_stat: 12,
rpc_createerr.cf_error.re_errno: 112
clnt_create_with_retry: Try #2: clnt_create: RPC: Remote system error - Address
already in use
clnt_create_with_retry: 13: clnt_create failed. rpc_createerr.cf_stat: 12,
rpc_createerr.cf_error.re_errno: 112
...
The errno 112 is EADDRINUSE and that's an odd thing to get, in this
case.
I'm kinda at wit's end on this and I'm hoping someone here has an
idea.
Below is hammernfs.c. It's made like this:
cc -O -o hammernfs.exe -I/usr/include/tirpc test/hammernfs.c \
test/hammernfs-libs/mount_xdr.c test/hammernfs-libs/mount_clnt.c \
test/hammernfs-libs/nfs_clnt.c test/hammernfs-libs/nfs_xdr.c -ltirpc
The hammernfs-libs/*.c files are available on the `devel' branch in
the git repo above. The hammernfs.c in that repo is slightly
different (the output is just slightly different, but the execution is
the same).
Thanks.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "hammernfs-libs/mount.h"
#include "hammernfs-libs/nfs.h"
struct file_handle {
int vers;
int len;
char data[FHSIZE3];
};
void print_fh(struct file_handle *fh) {
int i;
for(i=0; ilen; i++) {
printf("%02x", fh->data[i]);
}
}
void usage(char *prg) {
fprintf(stderr, "Usage: %s [ -q ] [ -v nfsvers ] [ -t test_duration ] [ -u uid ] [ -g gid ] [ -b blocksize ] [ -p udp|tcp ] [ -i label ] host:/export/path/to/file_to_read\n", prg);
exit(1);
}
/* Attempts to work around Windows + RDP disconnect strangeness */
CLIENT *clnt_create_with_retry(char *host, unsigned long program,
unsigned long version, char *proto) {
CLIENT *clnt;
int tries;
for (tries=0;tries<100;tries++) {
clnt=clnt_create(host, program, version, proto);
if (clnt) {
if (tries) {
fprintf(stderr, "%s: Try #%d: clnt_create succeeded.\n", __func__, tries+1);
}
return clnt;
}
fprintf(stderr, "%s: %d: clnt_create failed. rpc_createerr.cf_stat: %d, rpc_createerr.cf_error.re_errno: %d\n",
__func__, program, rpc_createerr.cf_stat, rpc_createerr.cf_error.re_errno);
if (rpc_createerr.cf_stat == RPC_SYSTEMERROR && rpc_createerr.cf_error.re_errno == EADDRINUSE) {
fprintf(stderr, "%s: Try #%d: %s\n", __func__, tries+1, clnt_spcreateerror("clnt_create"));
continue;
}
/* Some other failure that we don't handle */
return NULL;
}
return NULL;
}
struct file_handle *get_export_fh3(char *host, char *export, AUTH *auth) {
mountres3 *mountres;
CLIENT *clnt;
struct file_handle *fh;
clnt=clnt_create_with_retry(host, MOUNTPROG, 3, "udp");
if (!clnt) {
clnt_pcreateerror("clnt_create failed[1]");
exit(1);
}
clnt->cl_auth=auth;
mountres=mountproc3_mnt_3(, clnt);
if(mountres->fhs_status != MNT3_OK) {
printf("mount failed: status: %d\n", mountres->fhs_status);
exit(1);
}
fh=malloc(sizeof(struct file_handle));
if (!fh) {
perror("malloc");
exit(1);
}
fh->vers=3;
fh->len=mountres->mountres3_u.mountinfo.fhandle.fhandle3_len;
memcpy(fh->data, mountres->mountres3_u.mountinfo.fhandle.fhandle3_val,
fh->len);
if (clnt_freeres(clnt, (xdrproc_t)xdr_mountres3, (char *)mountres) != 1) {
printf("clnt_freeres failed\n");
exit(1);
}
clnt_destroy(clnt);
return fh;
}
struct file_handle *get_export_fh2(char *host, char *export, AUTH *auth) {
CLIENT *clnt;
fhstatus *fhstatus;
struct file_handle *fh;
clnt=clnt_create_with_retry(host, MOUNTPROG, 1, "udp");
if (!clnt) {
clnt_pcreateerror("clnt_create failed[2]");
exit(1);
}
clnt->cl_auth=auth;
fhstatus=mountproc_mnt_1(, clnt);
if (!fhstatus) {
printf("mountproc_mnt_1 returned NULL\n");
exit(1);
}
if (fhstatus->fhs_status != 0) {
printf("mount failed: status %d\n", fhstatus->fhs_status);
exit(1);
}
fh=malloc(sizeof(struct file_handle));
if (!fh) {
perror("malloc");
exit(1);
}
fh->vers=2;
fh->len=FHSIZE;
memcpy(fh->data, fhstatus->fhstatus_u.fhs_fhandle, FHSIZE);
if (clnt_freeres(clnt, (xdrproc_t)xdr_fhstatus, (char *)fhstatus) != 1) {
printf("clnt_freeres failed\n");
exit(1);
}
clnt_destroy(clnt);
return fh;
}
struct file_handle *get_export_fh(int vers, char *host, char *export,
AUTH *auth) {
switch(vers) {
case 2:
return
Re: SSH access to desktop
Here's what worked for me: Ran ssh-host-config as administrator and took defaults, except priviledge separation => no install as a service => no Then, I chown'd /var/empty to Administrator and was able to run "sshd -p 8100" and ssh into the box. More importantly, other users were able to start their own sshds, on different ports, and also ssh into the box. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
SSH access to desktop
I need to be able to SSH into a Windows machine with Cygwin installed and be able to run Windows programs and see the Windows they create. That is, when I run "notepad" I need to see the Window it creates. And, I need multiple users to be able to do this. In the past, I did this by having each user put an item in their Startup folder that did: C:\cygwin64\usr\sbin\sshd.exe -p 8100 where the port, 8100 in this case, is different for each user. The snag now seems to be: $ /usr/sbin/sshd.exe -p 8100 /var/empty must be owned by root and not group or world-writable. $ ls -l /var total 4 drwxr-xr-x+ 1 layer Domain Users 0 Mar 16 10:13 cache/ drwxr-x--x+ 1 Administrator Administrators 0 Mar 16 10:08 empty/ drwxr-xr-x+ 1 layer Domain Users 0 Mar 16 10:06 lib/ drwxrwxrwt+ 1 Administrators Administrators 0 Mar 16 15:08 log/ drwxrwxrwt+ 1 Administrators Administrators 0 Mar 16 10:51 run/ drwxrwxrwt+ 1 layer Domain Users 0 Apr 2 00:42 tmp/ $ The "in the past" is on an older version of Cygwin that hasn't been updated in a while. The new machine, where this is not working, is pretty up to date. Ideas? Thanks. Kevin -- 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: can't get sshd to new Windows 2012 R2 Server to work
Achim Gratz wrote: >> Kevin Layer writes: >> > I've tried various ssh-host-config permutations, but I just ran >> > >> > cygrunsrv.exe -R sshd >> > >> > and ran ssh-host-config with the defaults. I started the sshd service >> > and when I ssh to it: >> […] >> > If I give a command (e.g., env or pwd) I never get any output. >> > >> > This is a brand new server. All that is installed is Cygwin (latest, >> > just updated today), Windows Updates and Visual Studio 2015. Nothing >> > else, yet. >> >> Just install a 64bit Cygwin over the installation you already have. >> Seriously. Completely removed 32-bit cygwin. Installed 64-bit Cygwin. Same exact behavior. Anyone else? I need ssh into this box to work and I've previously never had trouble with Cygwin sshd. It's currently working fine on a Server 2008 R2 box. The firewall is off, I verified again. Thanks. Kevin -- 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
can't get sshd to new Windows 2012 R2 Server to work
I've tried various ssh-host-config permutations, but I just ran cygrunsrv.exe -R sshd and ran ssh-host-config with the defaults. I started the sshd service and when I ssh to it: @freon[git:master]$ ssh -vv4 thunder OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 ... debug1: Next authentication method: publickey debug1: Offering public key: /net/freon/home/layer/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug3: Wrote 372 bytes for a total of 1785 Connection closed by 192.132.95.185 @freon[git:master]$ If I give a command (e.g., env or pwd) I never get any output. This is a brand new server. All that is installed is Cygwin (latest, just updated today), Windows Updates and Visual Studio 2015. Nothing else, yet. Ideas? Thanks. Kevin Cygwin Configuration Diagnostics Current System Time: Tue Mar 15 23:30:19 2016 Windows 2012 R2 Server Standard Ver 6.3 Build 9600 Running under WOW64 on AMD64 Running in Terminal Service session Path: . C:\cygwin\home\layer\bink C:\cygwin\home\layer\bin C:\cygwin\fi\scm\bin C:\cygwin\usr\local\bin C:\cygwin\usr\local C:\cygwin\usr\sbin C:\cygwin\bin C:\cygwin\bin C:\Windows\System32 C:\Windows Output from C:\cygwin\bin\id.exe UID: 1049579(layer) GID: 1049089(Domain Users) 1049089(Domain Users) 559(Performance Log Users) 545(Users) 14(REMOTE INTERACTIVE LOGON) 4(INTERACTIVE) 11(Authenticated Users) 15(This Organization) 4095(CurrentSession) 66048(LOCAL)1054502(domcon2 $ Acronis Remote Users) 1055482(CERTSVC_DCOM_ACCESS)401408(Medium Mandatory Level) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'layer' PWD = '/var/log' HOME = '/home/layer' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin User: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS953516Mb 4% CP CS UN PA FC z: net NTFS 45418Mb 36% CP CS UN PApc C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,posix=0,auto Found: C:\cygwin\bin\awk Found: C:\cygwin\bin\awk -> C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\cpp.exe Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\find.exe Found: C:\Windows\System32\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gcc.exe Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\patch.exe Found: C:\cygwin\bin\patch.exe Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\home\layer\bin\ssh Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Found: C:\cygwin\bin\test.exe Found: C:\cygwin\bin\vi.exe Found: C:\cygwin\bin\vi.exe Not Found: vim 38k 2013/07/23 C:\cygwin\bin\cygargp-0.dll 87k 2016/02/26 C:\cygwin\bin\cygatomic-1.dll 14k 2012/05/04 C:\cygwin\bin\cygattr-1.dll 203k 2015/03/23 C:\cygwin\bin\cygblkid-1.dll 62k 2011/05/21 C:\cygwin\bin\cygbz2-1.dll 10k 2015/02/20 C:\cygwin\bin\cygcharset-1.dll 125k 2013/05/09 C:\cygwin\bin\cygcloog-isl-4.dll 13k 2015/03/19 C:\cygwin\bin\cygcom_err-2.dll 7k 2012/05/07 C:\cygwin\bin\cygcrypt-0.dll 2005k 2016/03/08 C:\cygwin\bin\cygcrypto-1.0.0.dll 485k 2016/02/08 C:\cygwin\bin\cygcurl-4.dll 1284k 2011/11/10 C:\cygwin\bin\cygdb-4.8.dll 105k 2011/11/10 C:\cygwin\bin\cygdb_cxx-4.8.dll 159k 2013/10/20 C:\cygwin\bin\cygedit-0.dll 153k 2013/07/31 C:\cygwin\bin\cygexpat-1.dll 27k 2015/01/02 C:\cygwin\bin\cygffi-6.dll 250k 2016/03/10 C:\cygwin\bin\cygfontconfig-1.dll 60k 2016/03/06
possible to see windows created via sshd?
I'm running sshd on Windows (Server 2008 R2). When I run Windows programs via ssh the windows are not visible. I realize this is a long shot, but is there any fix or workaround or hack to this? We run sshd under the cyg_server domain account. Thanks. Kevin -- 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: Google Calendar Command Line Interface
Gaspare Argento wrote: Hi, i have a question about the Google Command Line Tool present in Cygwin. I used googlecl to manage my Google Calendar Events until last November. Due to the deprecation of the Calendar GData API (v1, v2) made by Google this service now doesn't work. A good alternative could be gcalcli that support new Google Calendar API version 3. I'll second gcalcli. I moved to it recently because googlecl stopped working for calendar access. Kevin -- 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 on Max OS X ?
Richard H. McCullough wrote: I have an iMac 27 64-bit words running OS X Mavericks. Can I install Cygwin on my iMac? I know it's not necessary, but I thought it might be helpful for working on system porting/compatibility problems. Try macports.org if you need programs compatible with Cygwin's version, where either Mac OS doesn't have it (lots) or it's different (ssh). -- 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: ideas on how to debug an X server crash on Windows 8.1 (x64)?
I forgot to attach my XWin.0.log. Here it is: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.14.4.0 OS: CYGWIN_NT-6.3-WOW64 hobart256 1.7.27(0.271/5/3) 2013-12-07 16:27 i686 OS: Windows 8 [Windows NT 6.2 build 9200] (WoW64) Package: version 1.14.4-1 built 2013-11-11 XWin was started with the following command line: X :0 -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 1200 winInitializeScreenDefaults - native DPI x 96 y 96 [2371842.187] (--) Windows reports only 2 mouse buttons, defaulting to -emulate3buttons [2371842.187] Initializing built-in extension Generic Event Extension [2371842.187] Initializing built-in extension SHAPE [2371842.187] Initializing built-in extension MIT-SHM [2371842.187] Initializing built-in extension XInputExtension [2371842.187] Initializing built-in extension XTEST [2371842.187] Initializing built-in extension BIG-REQUESTS [2371842.187] Initializing built-in extension SYNC [2371842.187] Initializing built-in extension XKEYBOARD [2371842.187] Initializing built-in extension XC-MISC [2371842.187] Initializing built-in extension XINERAMA [2371842.187] Initializing built-in extension XFIXES [2371842.187] Initializing built-in extension XFree86-Bigfont [2371842.187] Initializing built-in extension RENDER [2371842.187] Initializing built-in extension RANDR [2371842.187] Initializing built-in extension COMPOSITE [2371842.187] Initializing built-in extension DAMAGE [2371842.187] Initializing built-in extension MIT-SCREEN-SAVER [2371842.187] Initializing built-in extension DOUBLE-BUFFER [2371842.187] Initializing built-in extension RECORD [2371842.187] Initializing built-in extension DPMS [2371842.187] Initializing built-in extension X-Resource [2371842.187] Initializing built-in extension GLX [2371842.187] (II) xorg.conf is not supported [2371842.187] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [2371842.187] LoadPreferences: Loading /home/layer/.XWinrc [2371842.187] LoadPreferences: Done parsing the configuration file... [2371842.203] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [2371842.203] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [2371842.203] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [2371842.203] winDetectSupportedEngines - Returning, supported engines 001f [2371842.203] winSetEngine - Multi Window or Rootless = ShadowGDI [2371842.203] winScreenInit - Using Windows display depth of 32 bits per pixel [2371842.234] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 1200 depth: 32 [2371842.234] winFinishScreenInitFB - Masks: 00ff ff00 00ff [2371842.234] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [2371842.234] winInitMultiWindowWM - Calling pthread_mutex_lock () [2371842.234] winMultiWindowXMsgProc - Calling pthread_mutex_lock () [2371842.250] MIT-SHM extension disabled due to lack of kernel support [2371842.250] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [2371842.281] GL_VERSION: 1.1.0 [2371842.281] GL_VENDOR: Microsoft Corporation [2371842.281] GL_RENDERER:GDI Generic [2371842.281] wglwrap: Can't resolve wglGetExtensionsStringARB [2371842.281] (EE) AIGLX: Won't use generic native renderer as it is not accelerated [2371842.296] (II) AIGLX: enabled GLX_EXT_texture_from_pixmap [2371842.296] (II) AIGLX: Loaded and initialized swrast [2371842.296] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [2371842.312] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [2371842.312] [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! [2371842.406] winPointerWarpCursor - Discarding first warp: 1920 600 [2371842.406] (--) 2 mouse buttons found [2371842.406] (--) Setting autorepeat to delay=500, rate=31 [2371842.406] (--) Windows keyboard layout: 0409 (0409) US, type 4 [2371842.406] (--) Found matching XKB configuration English (USA) [2371842.406] (--) Model = pc105 Layout = us Variant = none Options = none [2371842.406] Rules = base Model = pc105 Layout = us Variant = none Options = none [2371842.406] winBlockHandler - pthread_mutex_unlock() [2371842.406] winInitMultiWindowWM - pthread_mutex_lock () returned. [2371842.406] winInitMultiWindowWM - pthread_mutex_unlock () returned. [2371842.406] winMultiWindowXMsgProc - pthread_mutex_lock () returned. [2371842.406] winInitMultiWindowWM - DISPLAY=:0.0 [2371842.406] winMultiWindowXMsgProc - pthread_mutex_unlock () returned. [2371842.406] winProcEstablishConnection - winInitClipboard returned. [2371842.406] winClipboardThreadProc - DISPLAY=:0.0 [2371842.406] winMultiWindowXMsgProc - DISPLAY=:0.0 [2371842.406] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. [2371842.406] winClipboardProc
Re: Root/Administrator privileges from cygwin terminal
I use this:
userchar='$'
if [ ${WINDIR-} ]; then
if net session /dev/null 21; then
userchar='#'
fi
fi
export PS1=$PS1$userchar
I don't remember where I saw it, but it works well for me.
I don't know if it's worse or better, but I'll throw it out there.
Kevin
--
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: NTFS permissions still modified by rsyncd when using noacl
I noticed this, too, recently. I worked around it by running rsync over ssh, and that solved it for me. -- 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: startxwin started bash does not read .bashrc or .bash_profile
Earnie Boyd wrote: Then what is the value of $SHELL? /bin/bash What user actually starts the session? I've seen this type of thing when the cron daemon starts a session. The profile files are never read. Don't have cron running. I start it as me, the logged in user, from a mouse click or running startxwin in a mintty. Behaves the same either way. -- 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: startxwin started bash does not read .bashrc or .bash_profile
Earnie Boyd wrote: On Wed, Feb 27, 2013 at 5:16 PM, Kevin Layer wrote: Did you read the original report and all the replies in the chain? ...it requires my .bashrc to be sourced (.bash_profile merely sources .bashrc). Then what is the value of $SHELL? /bin/bash -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: startxwin started bash does not read .bashrc or .bash_profile
Robert Pendell wrote: Commonly .bash_profile does source in .bashrc so that it gets executed too. Exactly what mine does. I just want to be clear: I have not been able to get bash to source *anything* when started from startxwin.exe. I've done hours of experimentation and done many variations on how bash is started (from mintty, xterm, urxvt, ...) and I've not found a single working case. I've passed --init-file and --rcfile explicity. I've strace'd the startup of bash and only ever saw it open .bash_history. No touches to the init files. (I don't know how good strace is on cygwin, so this might not be definitive.) Can anyone else get their init file(s) loaded?? This seems like a serious bug. Btw, I set HOME in Windows to c:\cygwin\home\layer and not c:\Users\layer\. *BUT*, I have put in place dummy .bash_profile and .bashrc files that echo something and I've not seen that trigger during testing. -- 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: startxwin started bash does not read .bashrc or .bash_profile
Eliot, thanks for the reply. The passwd/group was an interesting thought. Unfortunately: @oob2$ mkpasswd -l passwd.new @oob2$ diff passwd passwd.new @oob2$ mkgroup -l group.new @oob2$ diff group group.new @oob2$ It's not just mintty. When I run xterm, it doesn't source any of my init files, either. This is not a new issue. I only started to care about it recently because I want to use ssh-agent/ssh-add in my .bashrc/.bash_profile. As for PATH, it's set so that it can find the programs, so I'm pretty sure that's neither here nor there. More ideas for debugging? Here's my mount output, in case that might be relevant: bash-4.1$ mount C:/cygwin/home on /home type ntfs (binary) C:/cygwin/bin on /usr/bin type ntfs (binary,noacl) C:/cygwin/lib on /usr/lib type ntfs (binary,noacl) C:/cygwin on / type ntfs (binary,noacl) C: on /c type ntfs (binary,noacl,posix=0,user) D: on /d type ntfs (binary,noacl,posix=0,user) E: on /e type vfat (binary,noacl,posix=0,user) Y: on /cygdrive/y type smbfs (binary,noacl,posix=0,user,noumount,auto) Z: on /cygdrive/z type ntfs (binary,noacl,posix=0,user,noumount,auto) bash-4.1$ Note that I added the /home entry to get `noacl' out of the options. However, this is a new thing, and as I said, the problem is old. Thanks. Kevin -- 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: startxwin started bash does not read .bashrc or .bash_profile
Jon TURNEY wrote: On 27/02/2013 00:08, Kevin Layer wrote: If I put this into .startxwinrc: mintty /usr/bin/bash.exe --login -i the resulting shell does not read .bash_profile. If I put mintty /usr/bin/bash.exe -i it doesn't read .bashrc. I've tried to reproduce this, but it seem to work ok for me. How can are you checking if ~/.bashrc has been read? Have you tried using bash -v to check what bash is reading? I know ~/.bashrc hasn't been read because my prompt is not changed and my aliases are not there. This is also a really odd place to start mintty. Why start it as a side effect of the unrelated action starting the X server? This is merely an example, the simplest one to reproduce the failure. It's not how I want to use startxwin. My ultimate goal is to use ssh-agent/ssh-add to make life easier, but it requires my .bashrc to be sourced (.bash_profile merely sources .bashrc). If you are going to work with both mintty and X clients, which will not naturally have a common parent ssh-agent process to inherit from, you might want to investigate the keychain package. I'm unfamiliar with that. Thanks for the pointer. Kevin -- 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: startxwin started bash does not read .bashrc or .bash_profile
K Stahl wrote:
I normally start a terminal in my .xinitrc file (Place it in your home
directory):
Example:
#!/usr/bin/sh
urxvt -e bash -l wmpid=$!
wait ${wmpid}
Bash started via .xinitrc *does* read my .bashrc. Interesting!
I'll play more with this tonight to see if I can get my ssh-agent/add
setup working with .xinitrc instead of .startxwinrc.
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: startxwin started bash does not read .bashrc or .bash_profile
Andrey Repin wrote: Greetings, Kevin Layer! I know ~/.bashrc hasn't been read because my prompt is not changed and my aliases are not there. That's just assumption. Not the first-hand knowledge. It may be true, or not... Best way to know is to place set -x around the start of the file and observe the results. That was one of the experiments I did, and I saw no evidence that any commands were executed. I even passed it as the argument to the invocation. As for the assumption, I understand that an error could have short-circuited the processing of my init file, but in the bash's that haven't read it, . .bashrc produces no errors *and* has my aliases and new prompt. Kevin -- 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: startxwin started bash does not read .bashrc or .bash_profile
Earnie Boyd wrote: On Wed, Feb 27, 2013 at 3:15 PM, Kevin Layer wrote: That was one of the experiments I did, and I saw no evidence that any commands were executed. I even passed it as the argument to the invocation. As for the assumption, I understand that an error could have short-circuited the processing of my init file, but in the bash's that haven't read it, . .bashrc produces no errors *and* has my aliases and new prompt. $HOME/.bashrc isn't always read. It depends on how bash is executed. If this is a --login you need $HOME/.bash_profile that sources $HOME/.bashrc. Did you read the original report and all the replies in the chain? ...it requires my .bashrc to be sourced (.bash_profile merely sources .bashrc). -- 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: startxwin started bash does not read .bashrc or .bash_profile
K Stahl wrote:
I normally start a terminal in my .xinitrc file (Place it in your home
directory):
Example:
#!/usr/bin/sh
urxvt -e bash -l wmpid=$!
wait ${wmpid}
Turns out, I'm mistaken, but I found out something interesting.
I had created a .xinitrc with a single xterm call in it, but I was
still running startxwin.exe instead of xinit.exe, so because I had
renamed .startxwinrc to .startxwinrc.disabled, I was running with some
default init file for startxwin.exe.
The xterm that comes up in this case *does* source my .bashrc.
From the man page:
startxwin
This will start up an XWin server and run the user's
.startxwinrc, if it exists, or else start an xterm.
So, the question is, why does the xterm that is started in the or
else behave different than the one started from .startxwinrc?
A big mystery to me.
--
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: startxwin started bash does not read .bashrc or .bash_profile
Btw, this happens on my home and work systems. Both Windows 7 Ultimate x64. -- 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: startxwin started bash does not read .bashrc or .bash_profile
Also, strace'ing startxwin was not fruitful--the program hangs without putting up any windows or doing much work at all. sigh I'm open to more suggestions... -- 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
startxwin started bash does not read .bashrc or .bash_profile
If I put this into .startxwinrc: mintty /usr/bin/bash.exe --login -i the resulting shell does not read .bash_profile. If I put mintty /usr/bin/bash.exe -i it doesn't read .bashrc. I've been beating my head against this wall for hours, over a few days. I've googled my ass off, but I can't find anyone that's having the same problem. My ultimate goal is to use ssh-agent/ssh-add to make life easier, but it requires my .bashrc to be sourced (.bash_profile merely sources .bashrc). 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: startxwin started bash does not read .bashrc or .bash_profile
Arthur Tu wrote:
On 2/27/2013 8:08 AM, Kevin Layer wrote:
If I put this into .startxwinrc:
mintty /usr/bin/bash.exe --login -i
the resulting shell does not read .bash_profile. If I put
mintty /usr/bin/bash.exe -i
it doesn't read .bashrc.
I've been beating my head against this wall for hours, over a few
days. I've googled my ass off, but I can't find anyone that's having
the same problem.
My ultimate goal is to use ssh-agent/ssh-add to make life easier, but
it requires my .bashrc to be sourced (.bash_profile merely sources
.bashrc).
Thanks.
## .bash_profile
if [ -f ${HOME}/.bashrc ] ; then
source ${HOME}/.bashrc
fi
What do you mean? Isn't this enough?
It is not. As I said, without --login, when .bashrc would be loaded
directly... it is *not*.
This should be pretty easy for someone to test. Does it work for
anyone else, as I've described?
I'm up to date on my installation as of today.
--
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
Need advice debugging a cygwin/git hang
I have scripts to fetch and rebase a list of 50+ repos. I run this on a 16-core AMD Windows Server 2008 R2 machine. In about 1 out of 10 times, I get a git fetch origin that uses 100% of a core until killed. It just happened again a few minutes ago: $ ps aux PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 2720 12720 2720 ? 11003 09:56:55 /usr/bin/bash 4704 14704 4704 ? 11003 10:12:15 /usr/bin/mintty 271247042712 3108 pty011003 10:12:15 /usr/bin/bash 534452485248 2508 ? 11003 10:07:37 /usr/bin/bash 3116 13116 3116 ? 11003 09:56:54 /usr/bin/bash 543213125248 6004 ? 11003 10:07:40 /usr/bin/ssh defunct 202827122028 3220 pty011003 10:18:48 /usr/bin/ps 469236884692 3600 ? 11003 09:56:21 /usr/bin/rsync 3688 13688 3688 ? 11003 09:56:21 /usr/bin/cygrunsrv 246813125248 4844 ? 11003 10:07:42 /usr/lib/git-core/git defunct 131253445248 1196 ? 11003 10:07:39 /usr/bin/git 5248 15248 5248 ? 11003 10:07:37 /usr/bin/bash 1580 11580 1580 ? 11003 09:56:57 /usr/bin/bash 1412 11412 1412 ? 11003 09:56:56 /usr/bin/bash I tried strace, but it got a Segmentation fault on both the above git processes. What can I do to debug this? 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: git clone over ssh fails intermittently w/snapshot 20120123
Corinna Vinschen wrote: On Feb 1 11:44, Kevin Layer wrote: Larry Hall (Cygwin) wrote: On 1/30/2012 5:53 PM, Kevin Layer wrote: Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll, changing nothing else on the machine. Can you check for the most recent snapshot that does work for you? It took a while, but it works in 11/24 and fails in 11/29. It did about ~500 clones on 11/24, so I'd say that's rock solid. Is this all that is needed? It's been all quiet since my email. You could test the latest snapshot 2012-02-01. I ran git on it for a couple of hours with no early EOF. Corinna, I'd say it's working. Done almost 200 clones and no failures. I'll let it run for a few hours and report if there are any failures. Thanks! Kevin -- 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: git clone over ssh fails intermittently w/snapshot 20120123
More than 2600 iterations. I'd say this snapshot doesn't have this particular bug. -- 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: git clone over ssh fails intermittently w/snapshot 20120123
Larry Hall (Cygwin) wrote: On 1/30/2012 5:53 PM, Kevin Layer wrote: Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll, changing nothing else on the machine. Can you check for the most recent snapshot that does work for you? It took a while, but it works in 11/24 and fails in 11/29. It did about ~500 clones on 11/24, so I'd say that's rock solid. Is this all that is needed? It's been all quiet since my 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: git clone over ssh fails intermittently w/snapshot 20120123
Larry Hall (Cygwin) wrote: On 1/27/2012 5:32 PM, Kevin Layer wrote: This is the failure mode: $ rm -fr test; git clone git:/repo/git/composer test Cloning into test... fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed Is this failure new or was it happening before this snapshot too? It did not happen before this snapshot. -- 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 -- 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: git clone over ssh fails intermittently w/snapshot 20120123
Christopher Faylor wrote: On Fri, Jan 27, 2012 at 02:32:54PM -0800, Kevin Layer wrote: I don't know what happened to the email in transit, but much information at the head of the email was chopped off. From my outbox, here's the missing bit: * This is the failure mode: $ rm -fr test; git clone git:/repo/git/composer test Cloning into test... fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed $ That is not using the git protocol. The machine is called `git'. It fails most of the time, but it definitely works sometimes, and even has stretches of successes. At first, I thought it was isolated to large repos, but it definitely happened on some smaller ones. You really haven't provided any details beyond git clone doesn't work along with cygcheck output. Well, I've shown the error message, and now answer the following questions. Hopefully that's enough. You've previously reported that git worked great. What changed? This is a different machine. What is the server that you're cloning from? Another windows machine running Cygwin? A linux box? Solaris? The server is a linux box. What does large repo mean to you? I just tried this on the gcc repo which is, from my point of view, pretty big. The clone succeeded without problem. As I said, it does *not* have to do with size. Where is the server located? Is it on a local network or is it from somewhere on the internet? Local area network. From my reading of the git documentation, using the host:/path syntax means you're using ssh to connect to the other machine. Have you checked the logs of the server to see if anything is reported? Have now and nothing. Is this new behavior just seen with this snapshot or is it something you noticed in 1.7.9? If you've just seen it in the latest snapshot it would be useful (as I've previously pleaded) to know in which snapshot the bad behavior first showed up. Never seen until the snapshot was installed. More info: Before the failure, I had removed and reinstalled cygwin, then installed the snapshot. The machine on which git works was upgraded little at a time. Kevin -- 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: git clone over ssh fails intermittently w/snapshot 20120123
Christopher Faylor wrote: On Mon, Jan 30, 2012 at 08:05:46AM -0800, Kevin Layer wrote: Christopher Faylor wrote: Is this new behavior just seen with this snapshot or is it something you noticed in 1.7.9? If you've just seen it in the latest snapshot it would be useful (as I've previously pleaded) to know in which snapshot the bad behavior first showed up. Never seen until the snapshot was installed. That isn't precise enough. Are you saying that you saw the problem in the 2012-01-23 snapshot but not in the 2012-01-22 snapshot? I'll bet that you aren't. If you think this is a problem only manifested in snapshots then we need to know which snapshot first had the problem. No. I didn't see it in 1.7.9, but do see it in the referenced snapshot. More info: Before the failure, I had removed and reinstalled cygwin, then installed the snapshot. The machine on which git works was upgraded little at a time. OTOH, little at a time might mean that you stepped through snapshots. No, I meant that the machine on which I've never seen the failure, even with the same 1/23 snapshot, had the packages on it upgraded once a month (roughly). I didn't remove everything and reinstall once a month, for example. On the machine that I have seen the errors, I removed everything, because I was in a weird state with my msysgit testing, so I thought it best to start from scratch. I removed msysgit and gnuwin32, as well. However, since the only change to 2012-01-23 was to tweak fifos and, as far as I know, git clone doesn't use a fifo, it's hard to see why there would be a regression in 2012-01-23. If you can think of some other tests I could perform, I'd be happy to do it. The machine with the failures is not a critical development machine, so it's pretty open to what I can 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: git clone over ssh fails intermittently w/snapshot 20120123
I've reverted the cygwin1.dll to the released 1.7.9 version. I will do a bunch of testing to see if I get clone failures, and report back. -- 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: git clone over ssh fails intermittently w/snapshot 20120123
I already got through one iteration of cloning all 52 repos, and I wasn't able to do that with the 1/23 snapshot in place. I'll keep running it, in a loop, to see if I ever get a failure. -- 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: git clone over ssh fails intermittently w/snapshot 20120123
Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll, changing nothing else on the machine. -- 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: git clone over ssh fails intermittently w/snapshot 20120123
I swapped back in the 1/23 cygwin1.dll and ran the test. It failed on the first clone. I'm done with my testing. Let me know if there's something else you want done. -- 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: git clone over ssh fails intermittently w/snapshot 20120123
Larry Hall (Cygwin) wrote: On 1/30/2012 5:53 PM, Kevin Layer wrote: Well over 200 clones with no error with the stock 1.7.9 cygwin1.dll, changing nothing else on the machine. Can you check for the most recent snapshot that does work for you? It took a while, but it works in 11/24 and fails in 11/29. It did about ~500 clones on 11/24, so I'd say that's rock solid. Kevin -- 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
git clone over ssh fails intermittently w/snapshot 20120123
Cygwin Configuration Diagnostics Current System Time: Fri Jan 27 14:24:45 2012 Windows 7 Ultimate Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Perl64\site\bin C:\Perl64\bin . C:\bin C:\sbin C:\cygwin\bin C:\cygwin\usr\local\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static C:\Program Files\Windows NT\Accessories C:\Program Files\3ware\CLI C:\Program Files (x86)\Common Files\Acronis\SnapAPI Output from C:\cygwin\bin\id.exe UID: 11003(layer) GID: 10513(Domain Users) 10513(Domain Users)0(root) 544(Administrators)545(Users) 1005(Acronis Remote Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'layer' PWD = '/c/tmp' CYGWIN = 'nodosfilewarning' HOME = '/home/layer' HOMEPATH = '\Users\layer.FRANZ' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Users\layer.FRANZ\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'hobart256' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 30 Stepping 5, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/home/layer' USERDOMAIN = 'FRANZ' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'layer' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' SHELLOPTS = 'braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' USERPROFILE = 'C:\Users\layer.FRANZ' LANG = 'en_US' PS1 = ' \w $(__dkl_git_branch [on branch \%s\]) \h$ ' LOGONSERVER = '\\DOMCON2' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\layer.FRANZ\AppData\Local' ProgramData = 'C:\ProgramData' SHLVL = '1' USERDNSDOMAIN = 'WIN.FRANZ.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\Windows' PRINTER = 'RICOH Aficio MP C4500 RPCS' PROCESSOR_REVISION = '1e05' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '4' COMPUTERNAME = 'HOBART256' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\c:\cygwin' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = 'c:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d (default) = 'd:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/e (default) = 'e:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/y (default) = 'y:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/z (default) = 'z:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin User: Key: c5e39b7a9d22bafb Path: c:\cygwin c: hd NTFS 49899Mb 59% CP CS UN PA FC HOBART256_C d: hd NTFS13Mb 67% CP CS UN PA FC HOBART256_D e: hd NTFS 48404Mb 13% CP CS UN PA FC HOBART256_E f: cd N/AN/A m: cd N/AN/A C:\cygwin/ system binary,auto c: /c system binary d: /d system binary e: /e system binary C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system
Re: git clone over ssh fails intermittently w/snapshot 20120123
I don't know what happened to the email in transit, but much information at the head of the email was chopped off. From my outbox, here's the missing bit: * This is the failure mode: $ rm -fr test; git clone git:/repo/git/composer test Cloning into test... fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed $ That is not using the git protocol. The machine is called `git'. It fails most of the time, but it definitely works sometimes, and even has stretches of successes. At first, I thought it was isolated to large repos, but it definitely happened on some smaller ones. -- 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: YA call for snapshot testing
Christopher Faylor wrote: On Tue, Jan 24, 2012 at 10:03:05PM -0800, Kevin Layer wrote: Larry Hall (Cygwin) wrote: This problem is killing me. I'm currently looking msysgit + GnuWin32 because I just can't take the crashes of bash.exe and git.exe anymore. In my testing, so far, I've never seen msysgit or the bash that comes with it crash. Why is it that cygwin has this problem but msysgit does not? It's an honest question and I'm not trying to be provocative. I've been a cygwin user since before Red Hat acquired them, and the above statement makes me really sad. Have you tried running rebaseall? Absolutely. After updating cygwin, I reboot and run rebaseall -v first thing. FYI, as far as I can tell the stack trace that you provided did not seem to come from the 20120123 snapshot. I'll investigate that. If not, install the rebase package and read its README to get the proper procedure for running rebaseall. This is a classic error message indicating colliding DLL addresses. Rebaseall (and sometimes peflags) are the prescribed solution in these cases. If that doesn't solve the problem, a complete problem report would be helpful. I have no idea how to make a reproducible test case of my system, composed of 50+ repos, is large and not open source. We have shell scripts that we use to apply git commands to each repo. One thing I've mentioned before: the problem became much worse when we switched development to a 16-core machine. It's running Server 2008 R2. Does anyone at Red Hat run on such a large-core machine? Why does that matter? This is a free software project staffed by one Red Hat person and a lot of people from other institutions. I'm really not sure what you're getting at... I was merely asking if the developers of Cygwin have tested on a 16-core machine. I think my problems all started when I and my developers started using it. The machine has been memtested, btw, and msysgit on the exact same repos operates flawlessly, in my tests so far. All other non-cygwin software on the machine works perfectly, too. If you think a bug report without a reproducible test case would be useful, let me know what info I can provide. Hmm. Can you actually conceive of a situation where, when reporting a bug, a reproducible test case is NOT useful? No, but I'm not a Cygwin expert, so I thought I'd ask. Barring a reproducible test case you could provide some of the information that I asked for in the thread that you're responding to. And, we always want to see cygcheck output with the additional details asked for. I'll read over the thread again and post it shortly. Kevin -- 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: YA call for snapshot testing
Christopher Faylor wrote: On Tue, Jan 24, 2012 at 10:03:05PM -0800, Kevin Layer wrote: Larry Hall (Cygwin) wrote: This problem is killing me. I'm currently looking msysgit + GnuWin32 because I just can't take the crashes of bash.exe and git.exe anymore. In my testing, so far, I've never seen msysgit or the bash that comes with it crash. Why is it that cygwin has this problem but msysgit does not? It's an honest question and I'm not trying to be provocative. I've been a cygwin user since before Red Hat acquired them, and the above statement makes me really sad. Have you tried running rebaseall? Absolutely. After updating cygwin, I reboot and run rebaseall -v first thing. FYI, as far as I can tell the stack trace that you provided did not seem to come from the 20120123 snapshot. OK, I didn't have the snapshot installed. It was the 1.7.9 dll. I had copied it in, then found I couldn't start bash, backed out the change, and rebooted, but I guess I forgot to redo it. I just installed it and did some testing, and it seems to be working OK. I'll report back if I see another crash. I just ran this test, in parallel on 4 different source trees (each composed of 52 repos): git fetch origin git rebase origin/master git status and not a single crash. It's usually good for 3-5 crashes, if I do them in parallel like that. Fingers crossed. NOTE: I run with CYGWIN=nodosfilewarning proc_retry:1 because I run a lot of non-cygwin software from shell scripts, and during testing, that can take 10's of minutes, I can't afford to have those programs restarted if they crash on exit. Before setting proc_retry:1, I once saw a loop of a 30 minute test run that went on for 10+ iterations. It would be really nice if you could apply proc_retry to cygwin programs only. Would that be possible? Then, I could remove that setting from CYGWIN and life would probably be better for me. -- 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: YA call for snapshot testing
I now have several hours of intense use, and I haven't seen one crash. Kudos to all that have contributed to this fix. -- 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: YA call for snapshot testing
Robert Miles wrote: NOTE: I run with CYGWIN=nodosfilewarning proc_retry:1 because I run a lot of non-cygwin software from shell scripts, and during testing, that can take 10's of minutes, I can't afford to have those programs restarted if they crash on exit. Before setting proc_retry:1, I once saw a loop of a 30 minute test run that went on for 10+ iterations. Are you able to put that CYGWIN setting inside the shell scripts that need it, and therefore not have it apply to any other scripts? For remotely executed stuff (an rsh-like program that allows execution of commands on a windows host), I use the trick of setting it on the command line. (It's unlike rsh in that it returns exit codes, and it pre-dates sshd for windows.) For stuff executed on the windows machine, we use a system env var that has it set. -- 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: YA call for snapshot testing
I wish I could report success like you. Using 20120123, just printing my prompt, which runs git rev-parse and git branch, I saw this (pd is an alias for pushd): thor$ pd /home/scm/acl90b.64 /home/scm/acl90b.64/src/cl/src 7 [main] bash 1732 c:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x99, top 0x9F, reserve_size 389120, allocsize 393216, page_const 4096 Stack trace: Frame Function Args 0028E4EC 6102796B (0028E4EC, , , 0028E53C) 0028E7DC 6102796B (6117EC60, 8000, , 61180977) 0028F80C 61004F1B (611B66CC, 0099, 009F, 0005F000) 0028F83C 6106E8C3 (7FFE, , 0010, 7778FE82) 0028F92C 610C133B (0068, 0200, 6116A724, 6116A720) 0028F95C 610064C0 (, 0002, , 76DE3480) 0028FA1C 6106FC15 (6100, 0001, 0028FD24, 0001) 0028FA3C 777A9950 (6106F960, 6100, 0001, 0028FD24) 0028FB30 777AD8C9 (0028FD24, 7EFDD000, 7EFDE000, 7787206C) 0028FCB0 777B681C (0028FD24, , 7726, ) 0028FD00 777B52D6 (0028FD24, , , ) 0028FD10 777A9E79 (0028FD24, , , 0001002F) End of stack trace 2 [main] bash 2640 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 bash: fork: retry: Resource temporarily unavailable 64bit /home/scm/acl90b.64 [on branch master] thor$ This problem is killing me. I'm currently looking msysgit + GnuWin32 because I just can't take the crashes of bash.exe and git.exe anymore. In my testing, so far, I've never seen msysgit or the bash that comes with it crash. Why is it that cygwin has this problem but msysgit does not? It's an honest question and I'm not trying to be provocative. I've been a cygwin user since before Red Hat acquired them, and the above statement makes me really sad. -- 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: YA call for snapshot testing
Larry Hall (Cygwin) wrote: This problem is killing me. I'm currently looking msysgit + GnuWin32 because I just can't take the crashes of bash.exe and git.exe anymore. In my testing, so far, I've never seen msysgit or the bash that comes with it crash. Why is it that cygwin has this problem but msysgit does not? It's an honest question and I'm not trying to be provocative. I've been a cygwin user since before Red Hat acquired them, and the above statement makes me really sad. Have you tried running rebaseall? Absolutely. After updating cygwin, I reboot and run rebaseall -v first thing. If not, install the rebase package and read its README to get the proper procedure for running rebaseall. This is a classic error message indicating colliding DLL addresses. Rebaseall (and sometimes peflags) are the prescribed solution in these cases. If that doesn't solve the problem, a complete problem report would be helpful. I have no idea how to make a reproducible test case of my system, composed of 50+ repos, is large and not open source. We have shell scripts that we use to apply git commands to each repo. One thing I've mentioned before: the problem became much worse when we switched development to a 16-core machine. It's running Server 2008 R2. Does anyone at Red Hat run on such a large-core machine? The machine has been memtested, btw, and msysgit on the exact same repos operates flawlessly, in my tests so far. All other non-cygwin software on the machine works perfectly, too. If you think a bug report without a reproducible test case would be useful, let me know what info I can provide. Thanks. Kevin -- 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: Cygwin 1.7.x on Windows 7: Exit statuses of Win32 executables are sometimes wrong
I want to go on record that it happening to us, too. And, I can say that it is happening *much* more since I moved to this machine: 2x AMD Opteron 6134 (16 cores total) Server 2008 R2 Enterprise, Service Pack 1 Software we have installed on the machine: ActivePerl AVG 9.0 Chrome Java 6 Update 26 Platform SDK (R2) (3790.2075) MSVC++ 6.0 (yeah, I know, old) VirtualCloneDrive (from Slysoft) 3ware disk management tools UltraVNC 1.0 server The previous machine had 2 cores and was running XP Pro, and had the same software on it. I hardly ever ran into this. Now, it's happens several times a day or so. -- 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
fork: retry: Resource temporarily unavailable
I'm testing a new machine. It's running Server 2008 R2 (64-bit) on a dual AMD Opteron 6134. The machine has 48GB of RAM and is nowhere near being used up. cygcheck -s at end. When running make, which spawns shell scripts from time to time, I see this: making testxgc.dll ../../version.sh: fork: retry: Resource temporarily unavailable ../../version.sh: fork: retry: Resource temporarily unavailable ../../version.sh: fork: retry: Resource temporarily unavailable ../../version.sh: fork: retry: Resource temporarily unavailable ../../version.sh: fork: Resource temporarily unavailable LINK : fatal error LNK1104: cannot open file '..\..\.obj' make[3]: *** [testxgc.dll] Error 80 rm testxgc.obj check compile-31.out for errors and/or warnings make[2]: *** [compile-tests-31] Error 1 make[1]: *** [dotest-31] Error 2 make: *** [all-tests0] Error 2 $ If I run again, it works fine. Hoping someone has some ideas on this. Thanks. Kevin cygcheck -s Cygwin Configuration Diagnostics Current System Time: Wed Jun 15 04:06:21 2011 Windows 2008 R2 Server Enterprise Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Running in Terminal Service session Path: . C:\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\Windows\system32 C:\Windows . C:\Windows\System32\Wbem C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin\WinNT C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin\win64\x86\AMD64 C:\openssl-1.0.0d.64\bin C:\Windows\System32\WindowsPowerShell\v1.0 Output from C:\cygwin\bin\id.exe UID: 11003(layer)GID: 10513(Domain Users) 10513(Domain Users) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows PWD = '/home/layer/acl82.64/src/cl/src' CYGWIN = 'nodosfilewarning' HOME = '/home/layer' Use '-r' to scan registry obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: c:\cygwin c: hd NTFS 2097050Mb 3% CP CS UN PA FC e: cd N/AN/A f: cd N/AN/A y: net NTFS 15118Mb 76% CP CS UN PApc z: net NTFS 15118Mb 76% CP CS UN PApc C: /c userbinary,noacl,posix=0 Y: /y userbinary,noacl Z: /z userbinary,noacl C:/cygwin/ system binary,noacl C:/cygwin/bin/usr/bin system binary,noacl C:/cygwin/lib/usr/lib system binary,noacl cygdrive prefix /cygdrive userbinary,noacl,posix=0,auto Found: C:\cygwin\bin\awk - C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Not Found: cpp (good!) Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\Windows\system32\find.exe Not Found: gcc Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Not Found: ld Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: .\patch Found: C:\cygwin\bin\patch.exe Found: .\patch Not Found: patch Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: .\test Found: C:\cygwin\bin\test.exe Found: .\test Not Found: test Found: C:\cygwin\bin\vi - C:\cygwin\bin\vim-nox.exe Found: C:\cygwin\bin\vim - C:\cygwin\etc\alternatives\vim - C:\cygwin\bin\vim-nox.exe 15k 2009/12/27 C:\cygwin\bin\cygattr-1.dll 62k 2011/05/21 C:\cygwin\bin\cygbz2-1.dll 7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll 1147k 2011/03/16 C:\cygwin\bin\cygcrypto-0.9.8.dll 284k 2010/06/01 C:\cygwin\bin\cygcurl-4.dll 943k 2007/12/17 C:\cygwin\bin\cygdb-4.5.dll 1296k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.5.dll 511k 2010/06/17 C:\cygwin\bin\cygedit-0.dll 118k 2008/05/09 C:\cygwin\bin\cygexpat-1.dll 43k 2010/01/02 C:\cygwin\bin\cygform-10.dll 40k 2009/03/01 C:\cygwin\bin\cygform-8.dll 47k 2010/01/02 C:\cygwin\bin\cygformw-10.dll 44k 2011/03/22 C:\cygwin\bin\cyggcc_s-1.dll 19k 2009/02/26 C:\cygwin\bin\cyggdbm-4.dll 8k 2009/02/26 C:\cygwin\bin\cyggdbm_compat-4.dll 315k 2009/06/06 C:\cygwin\bin\cyggmp-3.dll 25k 2011/01/26 C:\cygwin\bin\cyghistory7.dll 358k 2011/04/29 C:\cygwin\bin\cygicons-0.dll 980k 2011/01/28 C:\cygwin\bin\cygiconv-2.dll 193k 2010/05/16 C:\cygwin\bin\cygidn-11.dll 31k 2009/04/03 C:\cygwin\bin\cygintl-8.dll 5k 2011/03/29 C:\cygwin\bin\cyglsa.dll 9k 2011/03/29 C:\cygwin\bin\cyglsa64.dll 123k 2011/05/19 C:\cygwin\bin\cyglzma-5.dll 25k 2010/01/02 C:\cygwin\bin\cygmenu-10.dll 21k 2009/03/01 C:\cygwin\bin\cygmenu-8.dll 25k 2010/01/02 C:\cygwin\bin\cygmenuw-10.dll 211k 2009/06/06 C:\cygwin\bin\cygmp-3.dll 63k
strange error from rsync
I'm rsync'ing some files from a Windows XP SP3 box running the latest cygwin to a local disk on a linux box running Fedora 13. Here's the message: + rsync -qa --delete --delete-before rsync://hobart/src/ /backups/hobarts/hobart/c/src/2011.05.02-14:48:10 rsync: readdir(/. (in src)): No such file or directory (2) then is proceeds to rsync the entire contents of the remote directory, seemingly correctly. I've use rsync with Windows-Linux on other machines and don't see it there. Ideas? Kevin -- 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 1.7.8 + 3/18/11 snapshot + git = crash
Christopher Faylor wrote: On Wed, Mar 23, 2011 at 06:37:53PM -0400, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 05:25:03PM -0400, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 04:56:02PM -0400, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 09:08:48PM +0100, Corinna Vinschen wrote: On Mar 23 11:51, Kevin Layer wrote: On 03/22/2011 06:24 PM, Kevin Layer wrote: This is on Windows 7 64-bit. [...] CYGWIN_NT-5.2-WOW64 hobart128 1.7.9s(0.236/5/3) 20110323 01:32:07 i686 Cygwin Er... this isn't W7, that's XP or 2K3. Yeah, it would make sense if this was 64-bit Windows 2K3. I even saw some reports of this problem on W2K3. Unfortunately, sourceware's spam filter has several persistent (blocked due to a raw email address) attempts to report that it's XP 64. The most recent snapshot, dated 2011-03-23 21:41:22 may fix this problem. And, once again: http://cygwin.com/acronyms/#PCYMTNQREAIYR . Ping. I think the latest snapshot, but I'm not 100%. I removed the repo where I was getting the crash and started over. Kevin Hoping this email goes through. I reconfigured my email client (MH-E) to not include email addresses in the quoting of messages. -- 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 1.7.8 + 3/18/11 snapshot + git = crash
Christopher Faylor wrote: On Wed, Mar 23, 2011 at 06:37:53PM -0400, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 05:25:03PM -0400, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 04:56:02PM -0400, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 09:08:48PM +0100, Corinna Vinschen wrote: On Mar 23 11:51, Kevin Layer wrote: On 03/22/2011 06:24 PM, Kevin Layer wrote: This is on Windows 7 64-bit. [...] CYGWIN_NT-5.2-WOW64 hobart128 1.7.9s(0.236/5/3) 20110323 01:32:07 i686 Cygwin Er... this isn't W7, that's XP or 2K3. Yeah, it would make sense if this was 64-bit Windows 2K3. I even saw some reports of this problem on W2K3. Unfortunately, sourceware's spam filter has several persistent (blocked due to a raw email address) attempts to report that it's XP 64. The most recent snapshot, dated 2011-03-23 21:41:22 may fix this problem. And, once again: http://cygwin.com/acronyms/#PCYMTNQREAIYR . I would like to point out the email addresses I did quote, before I fixed the 30-year old behavior of MH-E (by redefining parts of it, since it's not customizable), were both *invalid* email addresses. Ping. Left out the word works. The latest snapshot works, I believe. -- 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 1.7.8 + 3/18/11 snapshot + git = crash
Eric Blake ebl...@redhat.com wrote: On 03/22/2011 06:24 PM, Kevin Layer wrote: This is on Windows 7 64-bit. The crash at the end left an index.lock file. Please let me know what I can do to help track down the problem. It's already tracked down - it's a bug in Microsoft's winmm.dll, and the latest snapshot cygwin1.dll works around it by avoiding that buggy dll. I'm using the 3/23/11 snapshot and I just got another crash, which looks the same: 0 [main] git-merge-recursive 4784 C:\cygwin\lib\git-core\git-merge-recursive.exe: *** fatal error - unable to load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Stack trace: Frame Function Args 00229E84 6102794B (00229E84, , , 00DFBF62) 0022A174 6102794B (6117EC60, 8000, , 61180997) 0022B1A4 61004F1B (61180101, 0022B1D0, 00A70290, ) 0022B404 61001756 (610EF441, 0022B430, 00A80280, 6120A220) 0022B448 6115EE2C (6123E0E0, 0022C700, , ) 0022B478 610EF7CE (0022B4C0, , 00F0, 00A80280) 0022B4D8 610C33B5 (0053A820, , 0124, 0010) 0022B4F8 00467C20 (0053A820, 0124, 0010, 00482D3E) 0022B528 00482F4A (0022C664, 0FFA, 00B90E98, 61073E46) 0022C628 0048315B (00BF1678, 764A, , 0007) 0022C688 00485A04 (00BF1678, 764A, 004F9642, 0022C6E8) 0022C738 004AE63D (0022C834, 0022C7F4, 61248A84, 61248C35) 0022C8E8 004B01E7 (81A4, 00B9EB7C, 81A4, 00B9EB94) 0022CA98 004B0FE5 (0022CB50, 00AA9C98, 00AA9CB8, 00AA9CD8) 0022CAD8 004B1589 (0022CB50, 00A9C148, 00AA8220, ) 0022CB28 004B17CC (0022CB50, 0022CC14, 0022CC00, 0001) End of stack trace (more stack frames may be present) /usr/lib/git-core/git-am: line 121: 4784 Hangup git-merge-recursive $orig_tree -- HEAD $his_tree Failed to merge in the changes. Patch failed at 0001 add regression files Just to verify: C:\cygwin\bindir cygwin1.dll Volume in drive C has no label. Volume Serial Number is E033-5FC1 Directory of C:\cygwin\bin 03/23/2011 07:21 AM 2,665,117 cygwin1.dll 1 File(s) 2,665,117 bytes 0 Dir(s) 17,147,928,576 bytes free C:\cygwin\bin -- 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 1.7.8 + 3/18/11 snapshot + git = crash
Chris Sutcliffe ir0nh...@gmail.com wrote: On 22 March 2011 21:33, Eric Blake wrote: On 03/22/2011 06:24 PM, Kevin Layer wrote: This is on Windows 7 64-bit. The crash at the end left an index.lock file. Please let me know what I can do to help track down the problem. It's already tracked down - it's a bug in Microsoft's winmm.dll, and the latest snapshot cygwin1.dll works around it by avoiding that buggy dll. 1 [main] git-merge-recursive 2864 C:\cygwin\lib\git-core\git-merge-recursive.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487 The list archives have more details. Based on Kevin's email subject, I assume he's already running the latest snapshot. I am now. See my most recent email. Kevin, can you please provide the output of 'uname -a'? CYGWIN_NT-5.2-WOW64 hobart128 1.7.9s(0.236/5/3) 20110323 01:32:07 i686 Cygwin 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
cygwin 1.7.8 + 3/23/11 snapshot + git = crash
I'm going to start a new thread, since I don't want the previous thread subject to make people miss it. Eric Blake ebl...@redhat.com wrote: On 03/22/2011 06:24 PM, Kevin Layer wrote: This is on Windows 7 64-bit. The crash at the end left an index.lock file. Please let me know what I can do to help track down the problem. It's already tracked down - it's a bug in Microsoft's winmm.dll, and the latest snapshot cygwin1.dll works around it by avoiding that buggy dll. I'm using the 3/23/11 snapshot and I just got another crash, which looks the same: 0 [main] git-merge-recursive 4784 C:\cygwin\lib\git-core\git-merge-recursive.exe: *** fatal error - unable to load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Stack trace: Frame Function Args 00229E84 6102794B (00229E84, , , 00DFBF62) 0022A174 6102794B (6117EC60, 8000, , 61180997) 0022B1A4 61004F1B (61180101, 0022B1D0, 00A70290, ) 0022B404 61001756 (610EF441, 0022B430, 00A80280, 6120A220) 0022B448 6115EE2C (6123E0E0, 0022C700, , ) 0022B478 610EF7CE (0022B4C0, , 00F0, 00A80280) 0022B4D8 610C33B5 (0053A820, , 0124, 0010) 0022B4F8 00467C20 (0053A820, 0124, 0010, 00482D3E) 0022B528 00482F4A (0022C664, 0FFA, 00B90E98, 61073E46) 0022C628 0048315B (00BF1678, 764A, , 0007) 0022C688 00485A04 (00BF1678, 764A, 004F9642, 0022C6E8) 0022C738 004AE63D (0022C834, 0022C7F4, 61248A84, 61248C35) 0022C8E8 004B01E7 (81A4, 00B9EB7C, 81A4, 00B9EB94) 0022CA98 004B0FE5 (0022CB50, 00AA9C98, 00AA9CB8, 00AA9CD8) 0022CAD8 004B1589 (0022CB50, 00A9C148, 00AA8220, ) 0022CB28 004B17CC (0022CB50, 0022CC14, 0022CC00, 0001) End of stack trace (more stack frames may be present) /usr/lib/git-core/git-am: line 121: 4784 Hangup git-merge-recursive $orig_tree -- HEAD $his_tree Failed to merge in the changes. Patch failed at 0001 add regression files Just to verify: C:\cygwin\bindir cygwin1.dll Volume in drive C has no label. Volume Serial Number is E033-5FC1 Directory of C:\cygwin\bin 03/23/2011 07:21 AM 2,665,117 cygwin1.dll 1 File(s) 2,665,117 bytes 0 Dir(s) 17,147,928,576 bytes free C:\cygwin\bin Kevin, can you please provide the output of 'uname -a'? CYGWIN_NT-5.2-WOW64 hobart128 1.7.9s(0.236/5/3) 20110323 01:32:07 i686 Cygwin Let me know if there is anything else I can do. Kevin -- 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
git issues with 1.7.8 + 3/13/11 snapshot of cygwin1.dll
I see this on my XP32 system: + git fetch Warning: No xauth data; using fake authentication data for X11 forwarding. From git:/repo/git/cl 75d375e..4ed5ea6 acl82 - origin/acl82 a5421cc..f0ac11c master - origin/master + git fetch --tags Warning: No xauth data; using fake authentication data for X11 forwarding. *** rebase instead of merge origin/acl82 src/code/random.cl| 14 +++- src/code/smp-macros.cl|5 +- src/code/smp-utilities.cl | 195 +++-- src/comp/q/qcon.cl| 22 + src/makefile.cl |2 +- 5 files changed, 138 insertions(+), 100 deletions(-) + git rebase --whitespace=nowarn origin/acl82 First, rewinding head to replay your work on top of it... fatal: Unable to create '/c/src/acl82/src/cl/.git/index.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. could not detach HEAD When I look in the .git directory, the file index.lock is *not* there. I suspect the file is lingering after the previous git fetch. I'm about to move up to the 3/18/11 snapshot. Anyone feel that will fix it? I never saw this before, when using the git + putty ssh hack on 1.7.7. -- 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: git issues with 1.7.8 + 3/13/11 snapshot of cygwin1.dll
When I look in the .git directory, the file index.lock is *not* there. Nevermind. I was looking in the wrong .git directory. There is a lock file there, presumably from before I started using the snapshot that fixed the git crashes. Sorry for the noise. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin 1.7.8 + 3/18/11 snapshot + git = crash
This is on Windows 7 64-bit. The crash at the end left an index.lock file. Please let me know what I can do to help track down the problem. Kevin + git rebase --whitespace=nowarn private/layer-scm First, rewinding head to replay your work on top of it... Applying: add regression files Using index info to reconstruct a base tree... stdin:326: trailing whitespace. nil))) stdin:631: trailing whitespace. nil))) stdin:940: trailing whitespace. nil))) stdin:1245: trailing whitespace. nil))) stdin:1550: trailing whitespace. nil))) warning: squelched 6 whitespace errors warning: 11 lines add whitespace errors. Falling back to patching base and 3-way merge... 1 [main] git-merge-recursive 2864 C:\cygwin\lib\git-core\git-merge-recursive.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Stack trace: Frame Function Args 00229E84 6102793B (00229E84, , , 0022A1C0) 0022A174 6102793B (6117EC60, 8000, , 61180997) 0022B1A4 61004F1B (61180101, 0022B1D0, 0130, 00A70250) 0022B404 61001756 (610EF431, 0022B430, 611BE1F0, 0022C6D8) 0022B448 6115EE2C (6123E0E0, , , ) 0022B478 610EF7BE (0022B4C0, , 8238, 00A600F0) 0022B4D8 610C33A5 (0053A820, , 0124, 0010) 0022B4F8 00467C20 (0053A820, 0124, 0010, 00482D3E) 0022B528 00482F4A (0022C664, 0FFA, 00B4A288, 61073E36) 0022C628 0048315B (00BB6ED8, 764A, , 0007) 0022C688 00485A04 (00BB6ED8, 764A, 004F9642, 0022C6E8) 0022C738 004AE63D (0022C834, 0022C7F4, 612437DC, 612482BD) 0022C8E8 004B01E7 (81A4, 00B9A084, 81A4, 00B9A09C) 0022CA98 004B0FE5 (0022CB50, 00AA9C18, 00AA9C38, 00AA9C58) 0022CAD8 004B1589 (0022CB50, 00A9C0C8, 00AA81A0, ) 0022CB28 004B17CC (0022CB50, 0022CC14, 0022CC00, 0001) End of stack trace (more stack frames may be present) /usr/lib/git-core/git-am: line 121: 2864 Hangup git-merge-recursive $orig_tree -- HEAD $his_tree Failed to merge in the changes. Patch failed at 0001 add regression files When you have resolved this problem run git rebase --continue. If you would prefer to skip this patch, instead run git rebase --skip. To restore the original branch and stop rebasing run git rebase --abort. -- 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
git fails with error 487 in winmm.dll
Anyone else seen this? hobart$ git reset --hard a000933 5 [main] git 2832 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Stack trace: Frame Function Args 0022AAF4 6102792B (0022AAF4, , , 28602020) 0022ADE4 6102792B (6117DC60, 8000, , 6117F977) 0022BE14 61004F3B (6117F101, 0022BE40, 7C90E920, 7C910060) 0022C074 6100176E (610EECC1, 0022C0A0, , 0022C2AC) 0022C0B8 6115DE2C (6123D0E0, 0022FF60, 7C839AD8, 7C802608) 0022C1E8 610EDD4F (6117E280, , 0022C31C, 0022C30C) 0022C2E8 610EE172 (6117E280, , 0022C31C, 0022C30C) 0022C338 610EE3D1 (, 0022C354, , 00616410) 0022C378 610C2C45 (005001B1, 000A, 0032, 0001) 0022C3F8 004AD278 (0001, 0022C570, 0022C420, 0022C420) 0022C5B8 00451D56 (0022CC08, 0022CC08, , 0022CA18) 0022CC38 00452535 (0003, 61243300, 0052B514, 0022CCD4) 0022CCE8 004017A9 (61244A74, 004DB17A, , ) 0022CD48 004019FE (, , 0022CD88, 61007048) 0022CD88 61007048 (, 0022CDC4, 61006990, 7FFDD000) End of stack trace Hangup hobart$ I do have a winmm.dll in c:\windows\system32\. What I have installed: hobart$ cygcheck -c Cygwin Package Information Package Version Status _update-info-dir 00949-1 OK alternatives 1.3.30c-10 OK base-cygwin 3.0-1 OK base-files 3.9-3 OK base-passwd 3.1-2 OK bash 4.1.10-4OK binutils 2.20.51-2 OK bzip21.0.6-1 OK coreutils8.10-1 OK cpio 2.11-1 OK crypt1.1-1 OK csih 0.9.4-1 OK ctags5.8-1 OK cvs 1.12.13-10 OK cvsps2.2b1-1 OK cygrunsrv1.34-1 OK cygutils 1.4.4-1 OK cygwin 1.7.8-1 OK cygwin-doc 1.7-1 OK dash 0.5.6.1-2 OK diffutils2.9-1 OK ed 1.0-1 OK editrights 1.01-2 OK file 5.05-1 OK findutils4.5.9-2 OK gawk 3.1.8-1 OK gcc 3.4.4-999 OK gcc-core 3.4.4-999 OK gcc-g++ 3.4.4-999 OK gcc-mingw-core 20050522-1 OK gcc-mingw-g++20050522-1 OK gettext 0.17-11 OK git 1.7.4-1 OK git-gui 1.7.4-1 OK gitk 1.7.4-1 OK grep 2.6.3-1 OK groff1.20.1-2OK gzip 1.3.12-2OK ipc-utils1.0-1 OK less 436-1 OK libattr1 2.4.43-1OK libaudio21.9.2-1 OK libbz2_1 1.0.6-1 OK libcompface0 1.5.2-11OK libcurl4 7.20.1-1OK libdb4.5 4.5.20.2-2 OK libedit0 20090923-1 OK libexpat12.0.1-1 OK libfontconfig1 2.8.0-1 OK libfreetype6 2.3.12-1OK libgcc1 4.3.4-3 OK libgdbm4 1.8.3-20OK libgmp3 4.3.1-3 OK libICE6 1.0.6-1 OK libiconv21.13.1-2OK libidn11 1.18-1 OK libintl3 0.14.5-1OK libintl8 0.17-11 OK libjbig2 2.0-11 OK libjpeg626b-21 OK libjpeg7 7-10OK liblzma1 4.999.9beta-11 OK libncurses10 5.7-18 OK libncurses8 5.5-10 OK libncurses9 5.7-16 OK libncursesw105.7-18 OK libopenldap2_3_0 2.3.43-1OK libopenssl0980.9.8r-1OK libpcre0 8.02-1 OK libpng12 1.2.44-1OK libpopt0 1.6.4-4 OK libpq5 8.2.11-1OK libreadline7 6.1.2-2 OK libsasl2 2.1.23-1OK libsigsegv2 2.8-1 OK libSM6 1.1.1-2 OK libssh2_11.2.5-1 OK libssp0 4.3.4-3 OK libstdc++6 4.3.4-3 OK libtiff5 3.9.2-1 OK libuuid1 2.17.2-1OK libwrap0 7.6-21 OK libX11_6 1.3.3-1 OK
Re: git fails with error 487 in winmm.dll
Eric Blake ebl...@redhat.com wrote: On 03/15/2011 06:40 PM, Kevin Layer wrote: Anyone else seen this? hobart$ git reset --hard a000933 5 [main] git 2832 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487 Yes. Multiple people. And it's already fixed in the latest snapshot. Indeed it is. 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
ever thought of adding fwknop to ports collection?
I just installed it from source the other day, after checking to see if it was in cygwin. http://www.cipherdyne.org/fwknop/download/ -- 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: git stopped working with 1.7.1
Eric Blake ebl...@redhat.com wrote: On 03/11/2010 04:03 PM, Charles Wilson wrote: If it is not being worked on... I agree with Brian. This is a serious impediment to using Cygwin 1.7. I would think it would be of top priority. Only people who experience the problem can diagnose, debug, and fix it. git works fine for me under cygwin-1.7.1 (Vista, NTFS), so... Has the cygwin git maintainer been able to verify/reproduce the error? If not, then there's no way he can help you. I have sometimes seen the problem, but it has never been a show-stopper for me (I fall back to http cloning), and, so far, it has not percolated high enough to the top of my TODO list to be worth the investment of my time on it. I notice it is still broken (as of last week when I updated to the latest versions of everything and tested it). Any further news on when will be fixed? As for it not being a show-stopper for you, I just want to point out that there are many of us out here that do not have the luxury of switching to HTTP cloning when this fails. So, for us, it's a show-stopper that requires us to use putty to use git at all. Thanks. Kevin -- 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: git stopped working with 1.7.1
Brian L. br...@blucz.com wrote: From this thread I gather that little or no progress has been made on addressing the root cause of this issue. It still seems to be broken with the latest 1.7 series packages. What is the proper method for getting this bug in front of the guys who maintain the openssh package? The cygwin website suggests that the mailing list is the proper channel, but it doesn't seem like anyone's seriously looking into this as an openssh issue. It's clearly affecting more than a few users and the workaround, while reliable, is quite lame. Can this please get a little bit more priority? and another month goes by... If there is work going on behind the scenes, it would be nice to hear from the developer(s) working on it. If it is not being worked on... I agree with Brian. This is a serious impediment to using Cygwin 1.7. I would think it would be of top priority. Thanks. Kevin -- 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: git stopped working with 1.7.1
Eric Blake e...@byu.net wrote: According to Kevin Layer on 1/8/2010 11:01 AM: Has anyone in the cygwin group reproduced this? Yes, as maintainer of the git package on cygwin, I've seen sporadic failures of the git protocol, which I have always ended up working around by switching over to an http protocol. I'm assuming that it might either be BLODA or an actual bug in cygwin1.dll regarding handling of socket fds across forks, but haven't ever been bothered by it enough to try and debug it, because the workaround of http always works. Some of us can't use git w/HTTP, so I hope this gets fixed sooner rather than later. Kevin -- 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: git stopped working with 1.7.1
Eric Blake e...@byu.net wrote: Yes, as maintainer of the git package on cygwin, I've seen sporadic failures of the git protocol, which I have always ended up working around by switching over to an http protocol. I'm assuming that it might either be BLODA or an actual bug in cygwin1.dll regarding handling of socket fds across forks, but haven't ever been bothered by it enough to try and debug it, because the workaround of http always works. Also, given that other versions of SSH work with the 1.7 git, I would think this is pretty good evidence that it's a bug in cygwin1.dll. Date: Thu, 31 Dec 2009 14:04:16 -0500 Message-ID: 6ee4c8380912311104i1869d73dk818e041f2d8b2...@mail.gmail.com Subject: Re: git stopped working with 1.7.1 From: Brian L. br...@blucz.com To: cygwin@cygwin.com ... The problem seems to be rooted in cygwin's openssh package. If I point GIT_SSH at plink.exe (from the putty distribution) and configure pageant properly for keyless login then git works fine. -- 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: git stopped working with 1.7.1
Has anyone in the cygwin group reproduced this? -- 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: git stopped working with 1.7.1
David Antliff david.antl...@gmail.com wrote: On Thu, Dec 24, 2009 at 07:55, Kevin Layer la...@franz.com wrote: la...@hobart128 /c/tmp $ git clone git:/repo/git/acl acl.test Initialized empty Git repository in /c/tmp/acl.test/.git/ remote: Counting objects: 9205, done. remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed I'm no git expert, but that looks to me like the remote side (where the repository is stored) is experiencing the error while it's preparing data for transfer, and your local git is simply reporting the remote error. It also looks like the remote side is actually the same machine but you're using the git:// protocol to access it without specifying a remote server. I've never tried this and would have expected instead to see something like: I'm not using the git protocol. Note the single slash. The machine is named `git', which is what is confusing you. Anything of the form foo:/path uses SSH, which is what this is using. The server is hanging up, yes, but perhaps the client isn't sending the right responses. Since it looks like the remote is on the same machine as your shell, do you have write access to the actual repository? If so, you could run git-fsck on the repository to make sure it's intact. No, it's on a different machine, but there is absolutely nothing wrong with the repo. I've tried *THREE* Windows machines now. On all, git stops working when cygwin is upgraded. Works before. Doesn't work after. Period. It is not a problem on the server. There are 10+ of people using it every minute of the day and no one has had a problem. Ever. What about other repositories, do they behave the same way, or is your problem restricted to this one? It's random (at what percentage) where it dies (with this repo). It randomly dies with other repos, too. I did install 1.5.25 on the 64-bit Windows 7 machine and git works fine. I've sucked an enormous amount of data off the git server with it, too, and not one problem. Kevin -- 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: git stopped working with 1.7.1
Brian L. br...@blucz.com wrote: I'm seeing very similar bad behavior from cygwin+git on win7 x64 as well as winxp x86. This bug is not confined to 64 bit platforms. This bug is new in 1.7.x--I have cygwin 1.5 installs on both of these machines that do not exhibit this failure. The problem seems to be rooted in cygwin's openssh package. If I point GIT_SSH at plink.exe (from the putty distribution) and configure pageant properly for keyless login then git works fine. Good sleuthing! -- 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: git stopped working with 1.7.1
David Antliff david.antl...@gmail.com wrote: It may be a 64-bit issue, so I'll try a 32-bit machine, if I can scrounge one up. We are using WinXP 32-bit and have not seen this problem (yet). It would be really helpful (to me at least) to know whether you can reproduce the issue with 32-bit Windows... I imagine there are a fair number of people using git in Cygwin because the Windows alternatives (msys, etc) do not provide a POSIX-like toolchain environment. Using Cygwin also allows scripts around git to operate on Linux with no modifications. That is why we use Cygwin anyway, and Cygwin + git is very important to us, FWIW. I just tried 32-bit Windows XP Pro. I upgraded from 1.5.25 and installed git (it wasn't previously on that machine). Failed the same way. Kevin -- 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: git stopped working with 1.7.1
crickets I'm a little surprised there are *no* replies to this thread, other than mine. (It's not like there is no traffic on the mailing list.) Can someone tell me what I need to do to interest people in this? Let me summarize: git clone fails with this: remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed The clone is via ssh from a box on my local (10 Gig) network. This has happened on *two* machines. Both 64-bit. One XP. One Windows 7. Both have all recent Windows updates. The Windows 7 box is a new one. I installed Windows, the Windows 7 SDK and then cygwin. Git is the first thing I tried, and it failed. The XP box I have used for years. I had a working git until the other day when I upgraded to cygwin 1.7.1--it fails just like the Windows 7 box after the upgrade. This seems serious. Do people just not use cygwin git? It may be a 64-bit issue, so I'll try a 32-bit machine, if I can scrounge one up. Thanks. Kevin -- 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
git stopped working with 1.7.1
la...@hobart128 /c/tmp $ git clone git:/repo/git/acl acl.test Initialized empty Git repository in /c/tmp/acl.test/.git/ remote: Counting objects: 9205, done. remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed la...@hobart128 /c/tmp $ This is on XP 64-bit. Also happens on Windows 7 64-bit (a fresh install of 1.7.1). I'm using binary mounts: $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) D:/cvs on /d/cvs type ntfs (text) C: on /c type ntfs (binary) D: on /d type ntfs (binary) E: on /e type ntfs (binary) X: on /x type smbfs (binary,notexec) Y: on /y type smbfs (binary,notexec) Z: on /z type smbfs (binary,notexec) N: on /cygdrive/n type smbfs (binary,posix=0,user,noumount,auto) la...@hobart128 /c/tmp $ At this point I have no idea what to do. Ideas would be appreciated. Thanks. Kevin Layer -- 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: git stopped working with 1.7.1
la...@hobart128 /c/tmp $ git clone git:/repo/git/acl acl.test Initialized empty Git repository in /c/tmp/acl.test/.git/ remote: Counting objects: 9205, done. remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed I should mention that the percentage at which it fails is random. Out of 40 times I've run the command above, it worked exactly 1 time. Usually, however, the failures are anwhere from 20% to 63% on the early EOFs line. Also, other people seem to be having the issue, too: http://stackoverflow.com/questions/1493645/git-fatal-remote-end-hung-up/1954050#1954050 -- 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: git stopped working with 1.7.1
la...@hobart128 /c/tmp $ git clone git:/repo/git/acl acl.test Initialized empty Git repository in /c/tmp/acl.test/.git/ remote: Counting objects: 9205, done. remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed la...@hobart128 /c/tmp $ I have no problem ssh'ing to the `git' host, btw. I went back to 1.5.25-15 and git works again (of course, it's an older version of git, 1.6.1.2). I tried to install 1.6.1.2 on 1.7.1, but it didn't work. The clone complained that the index-pack program was missing. I did the usual ./configure make make install so I'm not sure what else to try. I still have cygwin 1.7.1 installed on a Windows 7 machine, so I can try 1.6.1.2 if someone can help me get it installed properly. Since Windows 7 isn't supported with 1.5, I really need to figure this out. Thanks for any help you can provide. Kevin -- 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: git stopped working with 1.7.1
I tried to install 1.6.1.2 on 1.7.1, but it didn't work. The clone complained that the index-pack program was missing. I did the usual ./configure make make install so I'm not sure what else to try. I copied git-index-pack.exe from the build directory to /usr/local/libexec/git-core/ and now 1.6.1.2 behaves the same as the cygwin-built git: la...@hobart256 ~ $ git clone git:/repo/git/acl acl Initialized empty Git repository in /home/layer/acl/.git/ remote: Counting objects: 9205, done. remote: Compressing objects: 100% (3300/3300), done. fatal: The remote end hung up unexpectedly fatal: early EOFs: 32% (2946/9205) fatal: index-pack failed la...@hobart256 ~ So, it would seem that something in cygwin, not git, has made this fail, since git 1.6.1.2 is working for me with cygwin 1.5.25. Kevin -- 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: bash CRLF problems (I have read the recent announcement)
Eric Blake [EMAIL PROTECTED] wrote: read version foo1.out I prefer this to the echo -n, because the latter isn't supported on all the platforms I run on (aix, for one). Thanks for the help. You guys rock. Kevin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash CRLF problems (I have read the recent announcement)
Mark Fisher [EMAIL PROTECTED] wrote: if you change the echo's to echo -n you don't get the ^M chars, as it surpresses the CR in the output. is this possible on the real scripts you talk about, or is the version generating script/app not changeable? The only restriction is that it work on all 19 platforms that I build on, and I think that might. I'll test it. Thanks for this, and the other suggestion. Thanks Eric and Dan, too. I believe I have enough suggestions to make this work, and when I do I'll report back. Kevin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bash CRLF problems (I have read the recent announcement)
v0.0 ts=2005/10/26 10:49 No Cygwin services found. Cygwin Package Information Last downloaded files to: C:\downloads\cygwin.download Last downloaded files from: http://mirrors.kernel.org/sourceware/cygwin Package Version _update-info-dir 00471-1 alternatives 1.3.29a-1 ash 20040127-3 base-files 3.7-1 base-passwd 2.2-1 bash 3.2.5-7 bzip21.0.3-2 coreutils6.6-2 crypt1.1-1 cvs 1.11.17-1 cygrunsrv1.17-1 cygutils 1.3.0-1 cygwin 1.5.22-1 cygwin-doc 1.4-4 diffutils2.8.7-1 e2fsprogs1.35-3 editrights 1.01-1 expat1.95.8-1 file 4.16-1 findutils4.3.2-1 fontconfig 2.4.1-3 freetype22.1.9-1 gawk 3.1.5-4 gdbm 1.8.3-8 gettext 0.15-1 grep 2.5.1a-2 groff1.18.1-2 gzip 1.3.5-2 inetutils1.3.2-35 ioperm 0.4-1 less 381-1 libbz2_1 1.0.3-2 libcharset1 1.11-1 libdb4.2 4.2.52-1 libdb4.3 4.3.28-1 libfontconfig1 2.4.1-3 libfreetype262.1.9-1 libgdbm 1.8.0-5 libgdbm-devel1.8.3-8 libgdbm3 1.8.3-3 libgdbm4 1.8.3-8 libiconv 1.11-1 libiconv21.11-1 libintl 0.10.38-3 libintl1 0.10.40-1 libintl2 0.12.1-3 libintl3 0.14.5-1 libintl8 0.15-1 libncurses5 5.2-1 libncurses6 5.2-8 libncurses7 5.3-4 libncurses8 5.5-3 libpcre0 6.6-1 libpopt0 1.6.4-4 libreadline4 4.1-2 libreadline5 4.3-5 libreadline6 5.2-3 libXft 2.1.6-1 libXft1 1.0.0-1 libXft2 2.1.6-1 login1.9-7 make 3.81-1 man 1.6d-2 minires 1.00-1 mktemp 1.5-4 more 2.11o-3 ncftp3.2.0-1 ncurses 5.5-3 openssh 4.5p1-1 openssl 0.9.8d-1 openssl097 0.9.7l-1 patch2.5.8-8 pcre 6.6-1 pcre-devel 6.6-1 pcre-doc 6.6-1 perl 5.8.7-5 procps 3.2.6-1 psmisc 21.5-3 rsync2.6.6-1 run 1.1.10-1 sed 4.1.5-2 tar 1.16-1 termcap 20050421-1 terminfo 5.5_20061104-1 texinfo 4.8-3 time 1.7-1 unzip5.52-2 util-linux 2.12r-2 vim 7.0.122-1 wget 1.10.2-2 which1.7-1 whois4.7.17-1 X-startup-scripts1.0.11-1 xorg-x11-base6.8.99.901-1 xorg-x11-bin 6.8.99.901-1 xorg-x11-bin-dlls6.8.99.901-1 xorg-x11-bin-lndir 6.8.99.901-1 xorg-x11-etc 6.8.99.901-1 xorg-x11-fenc6.8.99.901-1 xorg-x11-fnts6.8.99.901-1 xorg-x11-libs-data 6.8.99.901-1 xorg-x11-xwin6.8.99.901-1 xterm202-1 zip 2.32-2 zlib 1.2.3-2 Use -h to see help about each section -- Kevin Layer [EMAIL PROTECTED]http://www.franz.com/ Franz Inc., 555 12th St., Suite 1450, Oakland, CA 94607, USA Phone: (510) 452-2000 FAX: (510) 452-0182 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash CRLF problems (I have read the recent announcement)
Larry Hall (Cygwin) [EMAIL PROTECTED] wrote: version=`cat foo1.out` ... Time to adjust your expectations. ;-) Text mounts write CRNL as EOLs for all files that are not explicitly opened as binary (or text for that matter). Text mounts remove the CR from EOLs read from files that are not explicitly opened as binary (or text). 'cat' explicitly opens the file as binary. What is the portable way to get the contents of foo1.out into a variable, getting proper translation of the end of lines? (If the answer is use `d2u' that is not portable.) I thought I was safe by using text mounts--I spent quite a while looking at the archives before posting and thought I had covered all bases. Kevin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with exit codes on 64-bit Windows XP Pro x64
Corinna Vinschen [EMAIL PROTECTED] wrote: I just applied a patch which should return the correct error code. Ah, yes, I forgot: Please test the next snapshot from http://cygwin.com/snapshots/ The problem is fixed. Thank you very much, Corinna. I'd like to second William's comments: cygwin and the cygwin development team rock! Kevin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with exit codes on 64-bit Windows XP Pro x64
Corinna Vinschen [EMAIL PROTECTED] wrote: On Feb 6 14:49, Kevin Layer wrote: I'm running the latest cygwin (1.5.19, see cygcheck below). My application is a native Windows app (64 and 32-bit). It includes no cygwin libraries and is not compiled with cygwin's gcc. When I execute cygwin programs from my app, however, the return value obtained from cygwin programs is always 0. More precisely, I spawn a particular cygwin program, say `make' or `sh', with CreateProcess(). When the program exits GetExitCodeProcess() always sets the exit status to 0, no matter what the real exit status was. I just applied a patch which should return the correct error code. Thanks! Thanks for the testcase, it's highly appreciated, though... it was a lot of code for emulating cmd's echo %errorlevel% ;-) Yeah. Originally, we thought it was a Microsoft bug... so we went the extra mile. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
problems with exit codes on 64-bit Windows XP Pro x64
/* demonstrate a bug in capturing the exit code from shell */
#include stdlib.h
#include stdio.h
#include stdarg.h
#include signal.h
#include string.h
#include errno.h
#define _POSIX_
#include windows.h
#include winsock.h
#include limits.h
main (int argc, char *argv[])
{
exit(1);
}
/* demonstrate a bug in capturing the exit code from shell */
#include stdlib.h
#include stdio.h
#include stdarg.h
#include signal.h
#include string.h
#include errno.h
#define _POSIX_
#include windows.h
#include winsock.h
#include limits.h
main (int argc, char *argv[])
{
int docommand(char *), res;
if (argc 1) {
res = docommand(argv[1]);
printf(result = %d\n, res);
} else {
printf(no command!\n);
}
}
char *make_command_line(char *cmdline)
{
char buf[1024];
sprintf(buf, sh -c \%s\, cmdline);
return strdup(buf);
}
int
docommand(char *cmdline)
{
STARTUPINFO startup_info;
PROCESS_INFORMATION process_info;
SECURITY_ATTRIBUTES security;
char *newcmdline;
DWORD status;
HANDLE output_write = 0;
HANDLE erroroutput_write = 0;
HANDLE input_read = 0;
HANDLE current_process;
memset(startup_info, 0, sizeof(startup_info));
startup_info.cb = sizeof(startup_info);
security.nLength = sizeof(security);
security.lpSecurityDescriptor = 0;
security.bInheritHandle = FALSE;
startup_info.dwFlags = STARTF_USESTDHANDLES;
current_process = GetCurrentProcess();
newcmdline=make_command_line(cmdline);
if (!DuplicateHandle(current_process,
GetStdHandle(STD_INPUT_HANDLE),
current_process,
input_read,
0,
TRUE, /* inherit this one */
DUPLICATE_SAME_ACCESS)) input_read = 0;
startup_info.hStdInput = input_read;
if (!DuplicateHandle(current_process,
GetStdHandle(STD_OUTPUT_HANDLE),
current_process,
output_write,
0,
TRUE, /* inherit this one */
DUPLICATE_SAME_ACCESS)) output_write = 0;
startup_info.hStdOutput = output_write;
if (!DuplicateHandle(current_process,
GetStdHandle(STD_ERROR_HANDLE),
current_process,
erroroutput_write,
0,
TRUE, /* inherit this one */
DUPLICATE_SAME_ACCESS)) erroroutput_write = 0;
startup_info.hStdError = erroroutput_write;
if ((startup_info.hStdInput == 0)
(startup_info.hStdOutput == 0)
(startup_info.hStdError == 0)) {
/* clear this bit */
startup_info.dwFlags = ~STARTF_USESTDHANDLES;
}
if (!CreateProcess(0, newcmdline, 0, 0,
1, /* inherit handles */
0x214,
0, 0, startup_info, process_info)) {
printf(CreateProces(%s) failed. error code %ld\n,
cmdline, GetLastError());
free(newcmdline);
return 1;
}
free(newcmdline);
ResumeThread(process_info.hThread);
CloseHandle(process_info.hThread);
/* Wait for the process to exit */
WaitForSingleObject(process_info.hProcess, INFINITE);
if(!GetExitCodeProcess(process_info.hProcess, status)) {
printf(GetExitCodeProcess failed! error %ld\n, GetLastError());
exit(1);
}
CloseHandle(process_info.hProcess);
return status;
}
Cygwin Configuration Diagnostics
Current System Time: Mon Feb 06 14:09:14 2006
Windows XP Professional Ver 5.1 Build 2600
Running under WOW64 on AMD64
Running in Terminal Service session
Path: .
c:\bin
c:\cygwin\bin
c:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Microsoft Platform SDK\Bin\.
C:\Program Files\Microsoft Platform SDK\Bin\WinNT\.
c:\Program Files\Debugging Tools for Windows 64-bit
c:\Program Files\Microsoft Platform SDK\bin\win64\x86\AMD64
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11003(layer)GID: 10513(Domain Users)
544(Administrators) 545(Users) 10512(Domain Admins)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11003(layer)GID: 10513(Domain Users)
544(Administrators) 545(Users) 10512(Domain Admins)
10513(Domain Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
PWD = '/c/acl80/src/cl/src'
CYGWIN = 'nontsec'
HOME = '/c'
Use '-r' to scan registry
c: hd NTFS238464Mb 4% CP CS UN PA FC
d: cd N/AN/A
e: cd N/AN/A
f: fd N/AN/A
g: fd N/AN/A
h: fd N/AN/A
i: fd N/AN/A
y: net NTFS 28040Mb 76% CP CSPAlayer
z: net NTFS 8350Mb 87% CP CSPApc
z: /z system textmode
y: /y system textmode
C:\cygwin/lib /usr/lib system textmode
C:\cygwin/bin /usr/bin system textmode
c: /c system textmode
C:\cygwin / system textmode
. /cygdrive system textmode,cygdrive
Found: c:\cygwin\bin\awk.exe
Found: c:\cygwin\bin\bash.exe
Re: problems with exit codes on 64-bit Windows XP Pro x64
[Interestingly, the text of my message was stripped out... here it is] I'm running the latest cygwin (1.5.19, see cygcheck below). My application is a native Windows app (64 and 32-bit). It includes no cygwin libraries and is not compiled with cygwin's gcc. When I execute cygwin programs from my app, however, the return value obtained from cygwin programs is always 0. More precisely, I spawn a particular cygwin program, say `make' or `sh', with CreateProcess(). When the program exits GetExitCodeProcess() always sets the exit status to 0, no matter what the real exit status was. Attached are 2 programs, exit1.c and bug.c. Compile with: cl bug.c bufferoverflowu.lib cl exit1.c bufferoverflowu.lib [cl is MS C/C++ version 14, found in the SDK.] Then, running on 64-bit windows: ./bug exit1 result = 0 Doing the experimentn on 32-bit Windows gets the output result = 1 Below are the files. Is this a known issue? Any chance of a fix? -- Kevin Layer [EMAIL PROTECTED]http://www.franz.com/ Franz Inc., 555 12th St., Suite 1450, Oakland, CA 94607, USA Phone: (510) 452-2000 FAX: (510) 452-0182 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with exit codes on 64-bit Windows XP Pro x64
Samuel Thibault [EMAIL PROTECTED] wrote:
Hi,
Kevin Layer, le Mon 06 Feb 2006 14:37:00 -0800, a écrit :
Content-Description: bug.c
/* demonstrate a bug in capturing the exit code from shell */
main (int argc, char *argv[])
{
int docommand(char *), res;
if (argc 1) {
res = docommand(argv[1]);
printf(result = %d\n, res);
} else {
printf(no command!\n);
}
}
There is no return res; here, is that on purpose ?
No, but it's not relevant to the problem. (The main text of my message
wasn't sent until later, since something stripped it out.)
Kevin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: sh/rm bug -- rm doesn't remove a file when run from cmd
I just found a case of `rm' failing in a makefile. I added SHELL = bash and the rm worked. Looks like the same deal. This seems pretty broken. I'm really wondering if anyone else Note: I have CYGWIN defined as nontsec. Also, I forgot to include a cygcheck: D:\acl62\src\clcygcheck -s -h -r Cygwin Win95/NT Configuration Diagnostics Current System Time: Tue Jan 28 14:46:58 2003 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: d:\acl62\src\cl\src c:\Perl\bin C:\ODI\OStore\bin . c:\bin C:\Cygwin\bin C:\Cygwin\usr\local\bin C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin C:\Program Files\Microsoft Visual Studio\Common\Tools C:\Program Files\Microsoft Visual Studio\VC98\bin d:\openssl-0.9.6\out32dll C:\Program Files\Resource Kit\ c:\j2sdk1.4.1_01\bin SysDir: C:\WINNT\System32 WinDir: C:\WINNT Here's some environment variables that may affect cygwin: CYGWIN = `nontsec' HOME = `C:/' Scanning registry for keys with `Cygnus' in them... HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0020 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `c:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d (default) = `d:' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/w (default) = `w:' flags = 0x010a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/x (default) = `x:' flags = 0x010a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/y (default) = `y:' flags = 0x010a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/z (default) = `z:' flags = 0x010a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options Listing available drives... Drv TypeSize Free Flags Name a: fd N/AN/A c: hd NTFS8997Mb 61% CP CS UN PA FC hobart_c d: hd NTFS 30255Mb 27% CP CS UN PA FC hobart_d l: cd CDFS 0Mb -2147483548%CS Audio CD m: cd N/AN/A x: net NTFS 68980Mb 56% CP CSPAacl y: net NTFS8408Mb 40% CP CSPAlayer z: net NTFS8350Mb 62% CP CSPApc fd=floppy, hd=hard drive, cd=CD-ROM, net=Network Share CP=Case Preserving, CS=Case Sensitive, UN=Unicode PA=Persistent ACLS, FC=File Compression, VC=Volume Compression Mount entries: these map POSIX directories to your NT drives. -NT- -POSIX--Type- -Flags- C:\cygwin / system textmode c: /c system binmode d: /d system textmode C:\cygwin/bin /usr/bin system textmode C:\cygwin/lib /usr/lib system textmode w: /w system binmode x: /x system binmode y: /y system binmode z: /z system binmode . /cygdrive usertextmode,cygdrive Looking to see where common programs can be found, if at all... Found: C:\Cygwin\bin\bash.exe Found: C:\Cygwin\bin\cat.exe Found: C:\Cygwin\bin\cpp.exe Found: C:\Cygwin\bin\find.exe Found: C:\Cygwin\bin\gcc.exe Found: C:\Cygwin\bin\gdb.exe Found: C:\Cygwin\bin\ld.exe Found: C:\Cygwin\bin\ls.exe Found: C:\Cygwin\bin\make.exe Found: C:\Cygwin\bin\sh.exe Looking for various Cygnus DLLs... (-v gives version info) 58k 2002/05/07 C:\Cygwin\bin\cygbz2-1.dll 847k 2003/01/09 C:\Cygwin\bin\cygcrypto-0.9.7.dll 644k 2002/12/08 C:\Cygwin\bin\cygcrypto.dll 45k 2001/04/25 C:\Cygwin\bin\cygform5.dll 35k 2002/01/09 C:\Cygwin\bin\cygform6.dll 19k 2002/02/20 C:\Cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\Cygwin\bin\cyghistory4.dll 20k 2002/10/10 C:\Cygwin\bin\cyghistory5.dll 929k 2002/06/24 C:\Cygwin\bin\cygiconv-2.dll 22k 2001/12/13 C:\Cygwin\bin\cygintl-1.dll 28k 2002/09/20 C:\Cygwin\bin\cygintl-2.dll 119k 2002/02/09 C:\Cygwin\bin\cygjpeg6b.dll 26k 2001/04/25 C:\Cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\Cygwin\bin\cygmenu6.dll 156k
sh/rm bug -- rm doesn't remove a file when run from cmd
I'm on Windows 2000sp3. I've seen this bug before, but it disappeared. Now, it's back. I recently updated to cygwin 1.3.19. Nothing else on my system has changed in a really long time. I rebooted, and that didn't fix it. Here's bug2.sh: ls -l $2 echo removing $2... rm $2 ls -l $2 First, it only happens from a cmd prompt. If I do it from a bash (started with cygwin.bat), it does _not_ fail. Using `sh', the rm fails and doesn't print anything, but using `bash' it works: D:\acl62\src\cl\srcls -l foo.out -rw-r--r--1 layerNone6 Jan 28 13:28 foo.out D:\acl62\src\cl\srcsh bug2.sh xxx foo.out -rw-r--r--1 layerNone6 Jan 28 13:28 foo.out removing foo.out... -rw-r--r--1 layerNone6 Jan 28 13:28 foo.out Didn't remove it. Hmmm. Let's see what bash does: D:\acl62\src\cl\srcbash bug2.sh xxx foo.out -rw-r--r--1 layerNone6 Jan 28 13:28 foo.out removing foo.out... ls: foo.out: No such file or directory Yep, worked. D:\acl62\src\cl\srcwhich sh /usr/bin/sh D:\acl62\src\cl\srcbash --version GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) Copyright (C) 2002 Free Software Foundation, Inc. D:\acl62\src\cl\src Again, it _only_ happens when run from a cmd prompt. Can anyone reproduce this? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sh/rm bug -- rm doesn't remove a file when run from cmd
An easier way of reproducing it: d:\acl62\src\cl\srcls -l foo.out -rw-r--r--1 layerNone6 Jan 28 14:39 foo.out d:\acl62\src\cl\srcsh -c 'rm foo.out' d:\acl62\src\cl\srcls -l foo.out -rw-r--r--1 layerNone6 Jan 28 14:39 foo.out d:\acl62\src\cl\srcrm foo.out d:\acl62\src\cl\srcls -l foo.out ls: foo.out: No such file or directory d:\acl62\src\cl\srcwhich rm /usr/bin/rm d:\acl62\src\cl\src I uninstalled my virus scanner (Norton 2002), thinking it might be the cause. No change. I tried another machine that has the same versions of all the cygwin programs as my machine. The bug does _not_ happen there. Does anyone have any clue where I can look? This bug is killing me. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sh/rm bug -- rm doesn't remove a file when run from cmd
Found the problem: I had a file named `rm': D:\acl62\src\cl\srcls -l rm -rw-r--r--1 layerNone0 Jan 28 15:47 rm D:\acl62\src\cl\srcgetfacl rm # file: rm # owner: layer # group: None user::rw- group::r-- other:r-- mask:rwx D:\acl62\src\cl\src Now, it seems odd that `sh' (but not `bash' nor `sh' on Solaris) would try and execute this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win2000, XEmacs 21.4.10, MH-E, cygwin 1.3.17-1
Peter Davis [EMAIL PROTECTED] wrote: On Sat, Jan 04, 2003 at 02:14:04AM +0900, Stephen J. Turnbull wrote: Peter == Peter Davis [EMAIL PROTECTED] writes: The procedure entry point _ctype_ could not be located in the dynamic link library cygwin1.dll Peter So why is XEmacs even *looking* in cygwin1.dll, since it's Peter the win32 installation? I doubt XEmacs is looking in cygwin1.dll. Most likely it's the MH binaries. Hmmm. That's even *more* puzzling, since I'm running the identical binaries on both machines. I have not succeeded in building nmh on Cygwin myself. If you have MSVC++, you can use `dumpbin /imports xemacs.exe' to see what dlls xemacs.exe (or whatever it's called) depends on. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bogus PATH transformations in bash 2.05a.0(3)-release w/cygwin 1.3.10
Just to make sure I understand. After doing a complete reinstall with the latest setup.exe, the mounts are now correct? Please confirm that with 'cygcheck -s' so I can put this to bed in my mind at least. Yes, reinstall with cleaning the registry. I've been a long time cygwin user, going back to the beta days, and I don't remember ever having cleaned out the registry from all the installs I've done. Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed May 22 09:57:05 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2 Path: d:\acl62\src\cl\src C:\ODI\OStore\bin . c:\bin C:\Perl\bin C:\Cygwin\bin C:\Cygwin\usr\local\bin C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin C:\Program Files\Microsoft Visual Studio\Common\Tools C:\Program Files\Microsoft Visual Studio\VC98\bin C:\NCFTP C:\Program Files\Resource Pro Kit d:\openssl-0.9.6\out32dll SysDir: C:\WINNT\System32 WinDir: C:\WINNT HOME = `C:/' MAKE_MODE = `UNIX' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS4329Mb 68% CP CS UN PA FC HOBART_C d: hd NTFS 29259Mb 38% CP CS UN PA FC HOBART_D l: cd CDFS 601Mb 100%CS UN QTR25ENUD1 m: cd N/AN/A w: net NTFS 68980Mb 26% CP CSPAinternal y: net NTFS8408Mb 59% CP CSPAlayer z: net NTFS8350Mb 75% CP CSPApc c: /c usertextmode d: /d usertextmode l: /l usertextmode w: /w usertextmode y: /y usertextmode z: /z usertextmode C:\cygwin / system textmode C:\cygwin/bin /usr/bin system textmode C:\cygwin/lib /usr/lib system textmode . /cygdrive usertextmode,noumount Found: C:\Cygwin\bin\bash.exe Found: C:\Cygwin\bin\cat.exe Found: C:\Cygwin\bin\cpp.exe Found: C:\Cygwin\bin\find.exe Found: C:\Cygwin\bin\gcc.exe Found: C:\Cygwin\bin\gdb.exe Found: C:\Cygwin\bin\ld.exe Found: C:\Cygwin\bin\ls.exe Found: C:\Cygwin\bin\make.exe Found: C:\Cygwin\bin\sh.exe 58k 2002/05/07 C:\Cygwin\bin\cygbz2-1.dll 621k 2002/05/17 C:\Cygwin\bin\cygcrypto.dll 45k 2001/04/25 C:\Cygwin\bin\cygform5.dll 35k 2002/01/09 C:\Cygwin\bin\cygform6.dll 19k 2002/02/20 C:\Cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\Cygwin\bin\cyghistory4.dll 20k 2002/01/13 C:\Cygwin\bin\cyghistory5.dll 22k 2001/12/13 C:\Cygwin\bin\cygintl-1.dll 21k 2001/06/20 C:\Cygwin\bin\cygintl.dll 81k 2000/12/05 C:\Cygwin\bin\cygitcl30.dll 35k 2000/12/05 C:\Cygwin\bin\cygitk30.dll 26k 2001/04/25 C:\Cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\Cygwin\bin\cygmenu6.dll 156k 2001/04/25 C:\Cygwin\bin\cygncurses++5.dll 175k 2002/01/09 C:\Cygwin\bin\cygncurses++6.dll 226k 2001/04/25 C:\Cygwin\bin\cygncurses5.dll 202k 2002/01/09 C:\Cygwin\bin\cygncurses6.dll 15k 2001/04/25 C:\Cygwin\bin\cygpanel5.dll 12k 2002/01/09 C:\Cygwin\bin\cygpanel6.dll 40k 2001/11/21 C:\Cygwin\bin\cygpcre.dll 39k 2001/11/21 C:\Cygwin\bin\cygpcreposix.dll 108k 2001/06/28 C:\Cygwin\bin\cygreadline4.dll 121k 2002/01/13 C:\Cygwin\bin\cygreadline5.dll 156k 2002/05/17 C:\Cygwin\bin\cygssl.dll 390k 2000/12/05 C:\Cygwin\bin\cygtcl80.dll 5k 2000/12/05 C:\Cygwin\bin\cygtclpip80.dll 10k 2000/12/05 C:\Cygwin\bin\cygtclreg80.dll 623k 2000/12/05 C:\Cygwin\bin\cygtk80.dll 50k 2002/03/12 C:\Cygwin\bin\cygz.dll 751k 2002/02/25 C:\Cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.3.10 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 51 Shared data: 3 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Mon Feb 25 11:14:34 EST 2002 Shared id: cygwin1S3 Cygwin Package Information Package Version ash 20020131-1 bash2.05a-3 binutils20011002-1 bison 1.35-1 byacc 1.9-1 bzip2 1.0.2-2 crypt 1.0-1 ctags 5.2-1 cvs 1.11.0-1 cygwin 1.3.10-1 diff1.0-1 diffutils 2.8.1-1
Re: bogus PATH transformations in bash 2.05a.0(3)-release w/cygwin 1.3.10
Your /usr/bin and /usr/lib mounts are incorrect. There were some problems with that with some versions of setup.exe, but I think that has been fixed now. I had the latest version of setup.exe (as of yesterday). I decided to remove cygwin, even cleaning out `cygwin' references in the registry and reinstall from scratch. I also removed the c:\cygwin\usr\bin element from my path, since it is apparently obsolete now. After reinstalling the problem is no longer there. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bogus PATH transformations in bash 2.05a.0(3)-release w/cygwin 1.3.10
I noticed that my windows programs see a strange and bogus PATH. It is demonstrated here, from cmd.exe: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. c:\PATH C:\Cygwin\bin;c:\cygwin\usr\bin;C:\Cygwin\usr\local\bin c:\bash -i bash-2.05a$ echo $PATH /bin:/usr/bin:/usr/local/bin bash-2.05a$ /c/winnt/system32/cmd Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. c:\path PATH=c:\cygwin\bin;c:\cygwin\\bin;c:\cygwin\usr\local\bin ===^^ c:\ Notice the bogus double backslash. Is this a known bug? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bogus PATH transformations in bash 2.05a.0(3)-release w/cygwin 1.3.10
It's worse than I suspected originally, when I thought I could get around it by not using bash. Now, without bash: makefile: SHELL = sh default: FORCE echo $(PATH) /c/winnt/system32/cmd FORCE: and now: D:\bugPATH C:\Cygwin\bin;c:\cygwin\usr\bin;C:\Cygwin\usr\local\bin D:\bugsh -i $ make echo /bin:/usr/bin:/usr/local/bin /bin:/usr/bin:/usr/local/bin /c/winnt/system32/cmd Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. D:\bugpath PATH=c:\cygwin\bin;c:\cygwin\\bin;c:\cygwin\usr\local\bin ===^^ D:\bug That path should be c:\cygwin\usr\bin, but the `usr' is missing. Is there a workaround for this? This bug is killing me. If I don't get a workaround soon, I'll have to go back to an older version. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bogus PATH transformations in bash 2.05a.0(3)-release w/cygwin 1.3.10
What does cygcheck -s say? Cygwin Win95/NT Configuration Diagnostics Current System Time: Tue May 21 20:37:06 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2 Path: C:\ODI\OStore\bin . c:\bin C:\Perl\bin C:\Cygwin\bin c:\cygwin\usr\bin C:\Cygwin\usr\local\bin C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin C:\Program Files\Microsoft Visual Studio\Common\Tools C:\Program Files\Microsoft Visual Studio\VC98\bin C:\NCFTP C:\Program Files\Resource Pro Kit d:\openssl-0.9.6\out32dll SysDir: C:\WINNT\System32 WinDir: C:\WINNT HOME = `c:\tmp' MAKE_MODE = `UNIX' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS4329Mb 67% CP CS UN PA FC HOBART_C d: hd NTFS 29259Mb 38% CP CS UN PA FC HOBART_D l: cd CDFS 601Mb 100%CS UN QTR25ENUD1 m: cd N/AN/A w: net N/AN/A y: net NTFS8408Mb 59% CP CSPAlayer z: net NTFS8350Mb 75% CP CSPApc c:/ /c usertextmode d:/ /d usertextmode e:/ /e usertextmode w: /w usertextmode y: /y usertextmode z: /z usertextmode . /cygdrive usertextmode,noumount c:\cygwin\ / system textmode c:\cygwin\/bin /usr/bin system textmode c:\cygwin\/lib /usr/lib system textmode . /cygdrive usertextmode,noumount Found: C:\Cygwin\bin\bash.exe Found: C:\Cygwin\bin\cat.exe Found: C:\Cygwin\bin\cpp.exe Found: C:\Cygwin\bin\find.exe Found: C:\Cygwin\bin\gcc.exe Found: C:\Cygwin\bin\gdb.exe Found: C:\Cygwin\bin\ld.exe Found: C:\Cygwin\bin\ls.exe Found: C:\Cygwin\bin\make.exe Found: C:\Cygwin\bin\sh.exe 58k 2002/05/07 C:\Cygwin\bin\cygbz2-1.dll 621k 2002/05/17 C:\Cygwin\bin\cygcrypto.dll 45k 2001/04/25 C:\Cygwin\bin\cygform5.dll 35k 2002/01/09 C:\Cygwin\bin\cygform6.dll 19k 2002/02/20 C:\Cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\Cygwin\bin\cyghistory4.dll 20k 2002/01/13 C:\Cygwin\bin\cyghistory5.dll 22k 2001/12/13 C:\Cygwin\bin\cygintl-1.dll 21k 2001/06/20 C:\Cygwin\bin\cygintl.dll 81k 2000/12/05 C:\Cygwin\bin\cygitcl30.dll 35k 2000/12/05 C:\Cygwin\bin\cygitk30.dll 26k 2001/04/25 C:\Cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\Cygwin\bin\cygmenu6.dll 156k 2001/04/25 C:\Cygwin\bin\cygncurses++5.dll 175k 2002/01/09 C:\Cygwin\bin\cygncurses++6.dll 226k 2001/04/25 C:\Cygwin\bin\cygncurses5.dll 202k 2002/01/09 C:\Cygwin\bin\cygncurses6.dll 15k 2001/04/25 C:\Cygwin\bin\cygpanel5.dll 12k 2002/01/09 C:\Cygwin\bin\cygpanel6.dll 40k 2001/11/21 C:\Cygwin\bin\cygpcre.dll 39k 2001/11/21 C:\Cygwin\bin\cygpcreposix.dll 108k 2001/06/28 C:\Cygwin\bin\cygreadline4.dll 121k 2002/01/13 C:\Cygwin\bin\cygreadline5.dll 156k 2002/05/17 C:\Cygwin\bin\cygssl.dll 390k 2000/12/05 C:\Cygwin\bin\cygtcl80.dll 5k 2000/12/05 C:\Cygwin\bin\cygtclpip80.dll 10k 2000/12/05 C:\Cygwin\bin\cygtclreg80.dll 623k 2000/12/05 C:\Cygwin\bin\cygtk80.dll 50k 2002/03/12 C:\Cygwin\bin\cygz.dll 751k 2002/02/25 C:\Cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.3.10 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 51 Shared data: 3 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Mon Feb 25 11:14:34 EST 2002 Shared id: cygwin1S3 Cygwin Package Information Package Version ash 20020131-1 bash2.05a-3 binutils20011002-1 bison 1.35-1 byacc 1.9-1 bzip2 1.0.2-2 crypt 1.0-1 ctags 5.2-1 cvs 1.11.0-1 cygwin 1.3.10-1 diff1.0-1 diffutils 2.8.1-1 fileutils 4.1-1 findutils 4.1.7-4 flex2.5.4-2 gawk3.0.4-1 gcc 2.95.3-5 gdb 20010428-3 gdbm1.8.0-4 grep2.5-1
