PLEASE TEST YOUR FS
On Wed, 7 Apr 2010 19:27:00 +0200 Corinna Vinschen asked: Can anybody reproduce this problem with trailing dots and spaces in filenames on other filesytems than netapp? It would be quite helpful to get feedback from people using filesystems which are recognized by Cygwin as nwfs, unixfs, mvfs, or cifs. For testing, try to create *in Cygwin* a file called foo. and a file foo . If it works, and if a following `ls' and `rm' on the file works as well, everything's fine. If some error occurs, especially No such file or directory, then that filesystem probably requires special handling just like netapp. Well it sort of worked. cd'ed to //fileserver/common/group/sysops touch foo rm foo touch foo rm foo rm: cannot remove ` foo ': No such file or directory touch foo. rm foo. touch foo ls -l foo -rw-r--r-- 1 0 Apr 7 18:23 foo rm foo touch foo. ls -l foo. -rw-r--r-- 1 0 Apr 7 18:24 foo. rm foo. touch foo rm foo /usr/lib/csih/getVolInfo . Device Type: 7 Characteristics: 10 Volume Name: common Serial Number : 2951612753 Max Filenamelength : 255 Filesystemname : NTFS Flags : 2b FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE Slightly wierd it failed initially and then started to behave. Fileserver is a centos 5.24 box running: samba-common-3.0.28-1.el5_2.1 Also one weird thing, not sure it's relevent but... I noticed if I typo'ed the 'cd //fileserver/bad/path' and got a permission denied error, it hung the bash shell. The cd didn't return to the prompt. In one case at least it killed the bash shell. -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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: looking for clean_setup.zip
Hello all: I have a couple of copies of clean_setup.zip now thanks to: Angelo Graziosi arnstein at pobox.com I have placed version 1.0700 on the web at: http://www.cs.umb.edu/~rouilj/cygwin/clean_setup.zip if somebody could arrange to host this at cygwin.com that would be terrific as this is my old college account and I would prefer to not heavily load it. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
Looking for clean_setup.pl/clean_setup.zip
Hi all: I am trying to find the clean_setup script done by Michael A Chase that used to be at: http://home.ix.netcom.com/~mchase/zip/clean_setup.zip but the home page (and I fear the script) is gone as well. I have tried the internet wayback machine without any luck. The html pages are there, but no copies of the zip archive are present. Does anybody have a copy of it that they can send to me? If so please contact me at rouilj at ieee dot org. When I get a copy I will post it. Thanks. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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: New setup.exe release candidate - unhandled exception
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: From: Max Bowsher Subject: New setup.exe release candidate - please test [...] http://www.cygwin.com/setup-snapshots/setup-2.459.exe [...] Please test - if no regressions are discovered in the next few days, it will I am getting an unhandled exception crash error. The setup.log reports: 2004/12/24 10:03:08 Starting cygwin install, version 2.459 2004/12/24 10:03:08 Current Directory: C:\progra~1\cygwin\pkgs 2004/12/24 10:03:08 Changing gid to Users 2004/12/24 10:03:08 Found McAfee anti virus program 2004/12/24 10:03:13 source: download 2004/12/24 10:03:14 Selected local directory: C:\progra~1\cygwin\pkgs 2004/12/24 10:03:15 net: Direct 2004/12/24 10:03:16 site: http://mirrors.rcn.net/pub/sourceware/cygwin 2004/12/24 10:03:16 site: http://planetmirror.com/pub/sourceware/cygwin 2004/12/24 10:03:16 site: http://www.egr.msu.edu/~huntharo/cygwin/ 2004/12/24 10:03:32 mbox fatal: Fatal Error: Uncaught Exception Thread: DialogProc Type: 9Exception Message: Package validation failure for file://C:\progra~1\cygwin\pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/cmake/cmake-1.8.3-1.tar.bz2 AppErrNo: 1 2004/12/24 10:03:48 Ending cygwin install System is windows 2000 sp4. I told it not to mess with the anti-virus program. sum of cmake tarball is 36654 1501. Running tar -tjvf on the file works fine. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
New setup.exe - unhandled exception more problem packages
Hi all: In an earlier email I sent in the details on an unhandled exception that I received while trying up update some packages. It originally occurred with the package: pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/cmake/cmake-1.8.3-1.tar.bz2.bad The following packages/tarballs (without the .bad extention) also had to be moved aside to allow the installer to complete and permit package selection. pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/gd/libgd-devel/libgd-devel-2.0.28-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/libXft/libXft-devel/libXft-devel-2.1.6-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-base/xorg-x11-base-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-bin/xorg-x11-bin-6.8.1.0-2.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-bin-dlls/xorg-x11-bin-dlls-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-bin-lndir/xorg-x11-bin-lndir-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-devel/xorg-x11-devel-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-etc/xorg-x11-etc-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-f100/xorg-x11-f100-6.8.1.0-3.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-fenc/xorg-x11-fenc-6.8.1.0-2.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-fnts/xorg-x11-fnts-6.8.1.0-3.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-fscl/xorg-x11-fscl-6.8.1.0-2.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-fsrv/xorg-x11-fsrv-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-libs-data/xorg-x11-libs-data-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-man-pages/xorg-x11-man-pages-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-man-pages-html/xorg-x11-man-pages-html-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-nest/xorg-x11-nest-6.8.1.0-1.tar.bz2.bad pkgs/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-vfb/xorg-x11-vfb-6.8.1.0-1.tar.bz2.bad I managed to get one download successfully after moving the packages aside. Now when I try to install from a local directory, I am pulling the same error from: pkgs/http%3a%2f%2fmirror.mcs.anl.gov%2fcygwin/release/doxygen/doxygen-1.2.18-1.tar.bz2 Also the funny thing is that the log file in pkgs/setup.log is not being updated when I do a local directory install. None of these problems are occurring with setup 2.427. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
Problem with sys.executable solved
I wrote a bit ago about sys.executable returning the current working directory. I am happy to report that the problem is solved, but I am not sure what caused the problem in the first place. The permissions on python2.3 were mode 000. This allowed python to run, but didn't allow it to do other things like resolve its own name. chmod 755 /usr/bin/python2.3.exe fixed the sys.executable problem. Now I have no idea what is broken with the permissions and why the file is being created with mode 000. I seem to remember a discussion of permissions with setup on NTFS filesystems. I thought it was fixed, but maybe not. Using setup, I removed the python 2.3.4-1 install and reinstalled it. The mode 000 file came back 8-(. I have attached the cygcheck.out in case its of any use. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. Cygwin Configuration Diagnostics Current System Time: Sun Jun 13 12:32:58 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: h:\local\bin C:\progra~1\cygwin\usr\X11R6\bin C:\progra~1\cygwin\tools\local\bin C:\progra~1\cygwin\usr\local\bin C:\progra~1\cygwin\bin C:\progra~1\cygwin\bin C:\progra~1\cygwin\bin C:\progra~1\cygwin\usr\X11R6\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\Program Files\Hummingbird\Connectivity\9.00\Security\Kerberos\ Output from C:\progra~1\cygwin\bin\id.exe (nontsec) UID: 80165(jrouilla) GID: 33507(hnm) 33507(hnm) Output from C:\progra~1\cygwin\bin\id.exe (ntsec) UID: 80165(jrouilla) GID: 33507(hnm) 0(root) 544(Administrators) 545(Users) 56787(CORP_CORP Melb Users) 56792(CORP_Domain Users)80542(corp_ExchWebmail) 80585(corp_hnm) 80595(corp_HNMGREEN)80646(corp_Netboss) 80665(corp_OA Office 2k PILOT) 80667(corp_OA Project2000) 80677(corp_OA_HNM_CQ2001) 80680(corp_OA_HNM_EXCEED) 80684(corp_OA_HNM_MIBPRO) 80685(corp_OA_HNM_ORACLE) 80722(corp_REMOTE-ACCESS) 10513(Domain Users) 33507(hnm) 38048(REMOTE-ACCESS) SysDir: C:\WINNT\system32 WinDir: C:\WINNT Here's some environment variables that may affect cygwin: CYGWIN = `server' HOME = `h:\' MAKE_MODE = `unix' PWD = `/h/develop' USER = `jrouilla' Here's the rest of your environment variables: ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\jrouilla\Application Data' COLORFGBG = `default;default;0' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `SC028764' COMSPEC = `C:\WINNT\system32\cmd.exe' CVSROOT = `:ext:137.237.15.156:/twiki/src/cvsroot' CVS_RSH = `ssh' DISPLAY = `:1' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\jrouilla' HOMESHARE = `\\mlbapp2\jrouilla$' LESS = `-eiMqX -h5 -j3' LOGONSERVER = `\\SC028764' MANPATH = `:/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/h/develop/sec' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PAGER = `less' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PS1 = `$PWD \! ' SCVER = `3.0b' SHLVL = `1' SMS_LOCAL_DIR = `C:\WINNT' SSH_AGENT_PID = `2032' SSH_AUTH_SOCK = `/tmp/ssh-aRgizi2036/agent.2036' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `c:\DOCUME~1\jrouilla\LOCALS~1\Temp' TERM = `rxvt' TMP = `c:\DOCUME~1\jrouilla\LOCALS~1\Temp' USERDNSDOMAIN = `cs.myharris.net' USERDOMAIN = `HARRIS' USERNAME = `jrouilla' USERPROFILE = `C:\Documents and Settings\jrouilla' VISUAL = `/h/local/bin/ec' WINDIR = `C:\WINNT' WINDOWID = `168329344' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' 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 = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\progra~1\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
sys.executable broken under 2.3.4
Hi all: I reported this in python 2.2.2 in December, and it's still an issue on one of my systems with python 2.3.4. When running python -c import sys; print sys.executable it prints the current working directory rather than the path to python unless I invoke python with the full path. I can't reproduce this on a win 98 box, but on a windows 2k sp4 things are broken. Can anybody reproduce this? Also does anybody have any ideas on how to find out what is happening without having to rebuild python and run a debugger through it? Am I correct in assuming that the problem is in the python binary and not is some python library? -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
Problem with pty allocation code, race condition?
Hello: I have noticed a problem when I start X windows. As part of my startup, I fire up three xterms, but only one of them actually completes and displays a prompt. I believe there may be a race condition in the pty allocation code as the three bash processes all share the same tty. ps -ef shows: UID PIDPPID TTY STIME COMMAND jrouilla23322252 1 09:04:19 /usr/bin/bash jrouilla23402248 1 09:04:19 /usr/bin/bash jrouilla23482168 1 09:04:19 /usr/bin/bash jrouilla26322332 1 09:05:01 /usr/bin/ps The one with pid 2332 I believe was the first to start based on the PID, but I also remember that the PID's are not monotonically increasing under cygwin so YMMV. However pid 2332 is the one (verified using echo $$) that I can interact with. The other two are frozen with no output or input (I entered a ^D which should have exited the shell). This failure usually occurs when I first log in in windows and run all my startup scripts. It is less likely to occur if I start up X after all the rest of the login processes have run, but I can provoke it here as well but with a lower frequency. A proper startup with three running bash/xterms looks like: UID PIDPPID TTY STIME COMMAND jrouilla24002216 1 09:11:05 /usr/bin/bash jrouilla26802204 3 09:11:05 /usr/bin/bash jrouilla27322188 4 09:11:06 /usr/bin/bash jrouilla27122400 1 09:11:09 /usr/bin/ps Does the last cygwin snapshot contain any code changes in the pty allocation area? If so I can try it and see if it helps. I am already running a snapshot from 20040412-23:00:24, but both 1.5.9 and this snapshot have the same issue AFAICT. It's an intermittent problem for me, but I will be happy to provide any info I can. I have attached the cygcheck output lightly edited to hide IP addresses and internal groups. If you need that info to debug the problem, I will send unedited output on request. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon May 17 09:16:25 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: h:\local\bin C:\progra~1\cygwin\usr\X11R6\bin C:\progra~1\cygwin\tools\local\bin C:\progra~1\cygwin\usr\local\bin C:\progra~1\cygwin\bin C:\progra~1\cygwin\bin C:\progra~1\cygwin\bin C:\progra~1\cygwin\usr\X11R6\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\Program Files\Hummingbird\Connectivity\9.00\Security\Kerberos\ Output from C:\progra~1\cygwin\bin\id.exe (nontsec) UID: 165(jrouilla) GID: 507(hnm) 507(hnm) Output from C:\progra~1\cygwin\bin\id.exe (ntsec) UID: 165(jrouilla) GID: 507(hnm) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) 33507(hnm) SysDir: C:\WINNT\system32 WinDir: C:\WINNT CYGWIN = `server' HOME = `h:\' MAKE_MODE = `unix' PWD = `/h' USER = `jrouilla' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\jrouilla\Application Data' COLORFGBG = `default;default;0' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `SC028764' COMSPEC = `C:\WINNT\system32\cmd.exe' CVSROOT = `:ext:127.0.0.1:/twiki/src/cvsroot' CVS_RSH = `ssh' DISPLAY = `:1' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\jrouilla' HOMESHARE = `\\mlbapp2\jrouilla$' LESS = `-eiMqX -h5 -j3' MANPATH = `:/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/c/Program Files/cygwin/bin' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PAGER = `less' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PS1 = `$PWD \! ' SCVER = `3.0b' SHLVL = `1' SMS_LOCAL_DIR = `C:\WINNT' SSH_AGENT_PID = `2076' SSH_AUTH_SOCK = `/tmp/ssh-fPZbxu1728/agent.1728' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `c:\DOCUME~1\jrouilla\LOCALS~1\Temp' TERM = `rxvt' TMP = `c:\DOCUME~1\jrouilla\LOCALS~1\Temp' USERDNSDOMAIN = `cs.myharris.net' USERDOMAIN = `HARRIS' USERNAME = `jrouilla' USERPROFILE = `C:\Documents and Settings\jrouilla' VISUAL = `/h/local/bin/ec' WINDIR = `C:\WINNT' WINDOWID = `168329344' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' 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
Problem with sys.executable in python.
Hi all: Can somebody with anup to date python please run the following program interactively: import sys print sys.executable When I run this, sys.executable returns the current working directory, not /usr/bin/python. I just had to have my machine rebuilt from an image, and I have already discovered that the restore doesn't preserve case, so things were/are kind of goofy in my cygwin installation. I reinstalled python and that cleaned up a lot of breakage. cygcheck -c cygwin python shows: Package VersionStatus cygwin 1.5.5-1OK python 2.3.2-1OK Does anybody know of a way to get cycheck to check the case of filenames/directories and report incorrect case as well? The brain dead approach of CYGWIN=check_case:strict cygcheck -c python didn't work. Not that I really expected it to since cygcheck isn't linked against cygwin1.dll -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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: startx and ssh
In message [EMAIL PROTECTED], Dr.D.J.Picton [EMAIL PROTECTED] said: [Gary Nicholson [EMAIL PROTECTED] said] I have been trying to de-bug a problem with startx. When I tried to run the file, I would get a server window, no clock and no terminal windows. The command-line errors were: .. Xlib: connection to 0.0 refused by server Xlib: No Protocol specified These error messages would repeat until I hit ^Z from the console command line. I found that the script would fail if a .Xauthority file existed in my home directory. If I removed the file, startx ran without errors; the server, the clock and the terminal windows all opened successfully when there was no .Xauthority file in my home directory. I found that the .Xauthority file was being created when I logged onto my Cygwin machine from another machine using ssh with the same login name. I am proposing a fix for this problem: In /usr/X11R6/bin/startx, add the following code before the block that exports the XAUTHORITY variable: # remove $HOME/.Xauthority if it exists if [ -f $HOME/.Xauthority ]; then rm $HOME/.Xauthority fi This code just removes .Xauthority if it exists. If .Xauthority doesn't exist, it does nothing. Does anyone have any feedback? I've seen the problem, and in my view there's a better solution. Remove the code which sets XAUTHORITY. (I think the problem occurs because XWin assumes -auth $XAUTHORITY if the variable is set, then gets upset because it can't find the authorization key for your display.) Even better, don't leave the X server wide open for everybody to screw with. The XFree-86 server includes the security extension (see xdpyinfo) so you should be able to generate a proper X authentication token for the display. Something like: xauth generate :0 . or xauth add $DISPLAY . `mcookie` added to the top of your ~/.xinitrc should do the trick. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions.
Re: why is bash trying to access my DNS? [OT]
On Mon, 2003-03-03 at 23:59, Randall R Schulz wrote: Geoffrey, =20 Exactly what sneaky data can get sent in a DNS request? [...] Actually, plenty. Historically, Bind has been easily hacked. Although it's been a while since a good vulnerablity was found in Bind, that doesn't mean there's not an unknown hole in it which could be exploited. However, in order to exploit such a hole, the attacking system has to be, in one way or another, owned. Anybody with the presence of mind to be running ZoneAlarm (or something similar) would certianly know if there system(s) had been compromised in such a fashion. Why is everybody assuming that a random host on the internet is running a dns server on port 53? Consider this senario: I put my machine on the internet. I then put a udp listener at port 53. I then distribute software that knows how to create a udp packet to port 53 on my host. I can send anything I want to to that port, files, passwords, registry entries... Just because its going to a DNS port does not mean that its DNS data. It just means that its data for the service at that particular IP Address/Port number. Now if you filter to certain hosts that you KNOW are running dns on port 53, then that is different. However that means you must keep updating the filter lists since I know my ISP changes my DNS servers almost every time I dial up. (My guess is they have a couple of DNS server per class C subnet/POP, but that's just a guess). Running ZoneAlarm gives you a hint that something bad may be going on when a program that shouldn't be making DNS queries starts making them. Or alternatively starts making queries tothe DNS port on joe blow's computer rather than a local network computer. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
Syslog-ng-1.5.24 build instructions for cygwin
Hi all:
Thanks go to whoever fixed the bug in cygwin1.dll that caused syslog
to fail as soon as a udp packet was sent to it. The bug was introduced
sometime around 1.3.12, but is fixed now. So here is my recipe for
building syslog-ng-1.5.24.
Download syslog-ng-1.5.24 and libol-0.3.6. Patch the syslog source
with the patch at the end of this message. The patch adds a -N flag to
stop the syslog server from forking so that windows services mechanism
and cygrunsrv will properly detect that the program/service is
running. The man page is updated with this flag, but the html/sgml
isn't patched. The patch also stops resolv.h from being included
under __CYGWIN__, and defined the typdef uint32_t as unsigned.
After applying the patch, touch src/main.c.x src/filter.c.x, then
configure and make the two packages. Then run cygrunsrv as:
cygrunsrv -I syslog -a '-N' -p /path/to/syslog -c /var/log
and
cygrunsrv -S syslog
I use the syslog server with backlog to send the event log on my
windows 2000 SP3 system to a file. I did most of my testing without
tcp wrappers enabled, but I did finally get it to compile with the
wrappers. To do this, change the lines that read:
old_LDFLAGS=$LDFLAGS
LDFLAGS=-lwrap
to read
old_LIBS=$LIBS
LIBS=-lwrap
and you will get
checking for hosts_access in -lwrap... yes
rather than
checking for hosts_access in -lwrap... no
Hopefully the syslog-ng people will include this patch in newer
versions.
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
diff -ur syslog-ng-1.5.24/doc/syslog-ng.8 syslog-ng-1.5.24.l/doc/syslog-ng.8
--- syslog-ng-1.5.24/doc/syslog-ng.81999-07-10 11:58:32.0 -0400
+++ syslog-ng-1.5.24.l/doc/syslog-ng.8 2003-01-12 11:30:30.0 -0500
@@ -7,7 +7,7 @@
.B syslog-ng
[
-.B \-dvV
+.B \-NdvV
] [
.B \-f
\fIconfig-filename\fP
@@ -76,6 +76,15 @@
.B \-p \0filename
Write the current PID information to the specified file.
.TP
+.B \-N
+Non-daemon mode. Adding \fB-N\fp to the command line will make syslog
+run in the foreground. This is used when starting syslog from service
+monitor programs in windows platforms using cygwin's cygrunsrv, but
+may also be useful for a startup/monitor wrapper that will restart
+syslog if it dies for some unusual reason. This does not cause any
+additional messages to be printed, so it will not fill up
+log files as \fB-d\fP or \fB-v\fP can.
+.TP
.B \-v
Enable verbose mode. Process will not become a daemon. Prints out
fewer messages, compared to \fB-d\fP.
diff -ur syslog-ng-1.5.24/src/filters.c syslog-ng-1.5.24.l/src/filters.c
--- syslog-ng-1.5.24/src/filters.c 2002-02-04 11:07:50.0 -0500
+++ syslog-ng-1.5.24.l/src/filters.c2003-01-12 11:21:57.0 -0500
@@ -259,6 +259,9 @@
struct log_filter *rule UNUSED,
struct log_info *log)
{
+#if defined(__CYGWIN__)
+ typedef unsigned uint32_t;
+#endif
CAST(filter_expr_netmask, self, c);
if (log-saddr) {
diff -ur syslog-ng-1.5.24/src/main.c syslog-ng-1.5.24.l/src/main.c
--- syslog-ng-1.5.24/src/main.c 2002-10-30 14:36:03.0 -0500
+++ syslog-ng-1.5.24.l/src/main.c 2003-01-12 11:31:31.0 -0500
@@ -46,7 +46,9 @@
#include arpa/nameser.h
#endif
-#include resolv.h
+#if ! defined(__CYGWIN__)
+ #include resolv.h
+#endif
#include main.c.x
@@ -425,7 +427,7 @@
gc_idle_threshold = 100;
gc_busy_threshold = 3000;
- while ((opt = getopt_long(argc, argv, sFf:p:dvhyVC:u:g:, syslog_ng_options,
NULL)) != -1) {
+ while ((opt = getopt_long(argc, argv, sFf:p:dvhyVC:u:g:N, syslog_ng_options,
+NULL)) != -1) {
switch (opt) {
case 'f':
strncpy(cfgfilename, optarg, sizeof(cfgfilename));
@@ -464,6 +466,9 @@
yydebug = 1;
break;
#endif
+ case 'N':
+ do_fork = 0;
+ break;
case 'h':
default:
usage();
--
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/
More experiences with snapshot setup-md5-20020504-compressed.exe
Hi all: Well I have a couple of more data points for the snapshot. Windows 2000 5.00.2195 Service Pack 1, 130kb of RAM from http://mirrors.rcn.net I was unable to get/parse setup.ini. I got a parse error popup that read: setup.ini line 2178 parser stack overflow setup.ini line 2178 parse error unexpected STRING setup.ini line 2178 unrecognized line in setup.ini headers (do you have the latest setup?) bunch more of these lines setup.ini line 2203 parse error unexpected \n.' expecting string ... setup.ini line 2206 parse error unrecognized SETUP_TIMESTAMP setup.ini line 2206 unrecognized line in pkg zlib ... setup.ini line 4376 parser stack overflow I also did downloads from ftp:gd.tuwein.ac.at, ftp:ftp.nas.nasa.gov, ftp:archive.progeny.com and http:planetmirror.com. Sometimes the line numbers were different. Also the errors grew the more I did the download from a site. Somtimes initially I would just get a parser stack overflow popup without the long list of errors. Then it would grow and give me the listing shown (in abbrevaited form above) then I sometimes got what looks like two sets of errors separated by a couple of thousand lines. When I downloaded the setup.ini files manually, they had less than 2100 or so lines in them. Obviously the setup.ini parser is going of the deep end, or the files are growing during xport 8-). Hmm, is the setup.ini temp file deleted when an error occurs? Where is this file kept? Its not in the http% directory since I still have my old setup.ini file there. /winnt/temp doesn't show it either. Now the funny part, I was sure that I had used this build to download and install some files on a Windows NT 4, sp5 box on Monday. However I just tried it again, and ended up getting the parse error failure. I didn't check but have the setup.ini files changed on the mirrors? I'll see if I can get a chance to rebuild the source and look at it. Also as an aside, it would be nice if that error box were able to handle selection and copy operations. Would make it easier to generate error reports. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
New setup.exe and crashes
In Message-ID: 030301c1a71f$8228eef0$0200a8c0@lifelesswks Robert Collins [EMAIL PROTECTED] wrote: o it seems to crash on certain mirrors - the ones I've had crash are ... note that the old setup.exe (2.125.2.10) works fine on the others I've uploaded a new setup.exe that shouldn't crash on *anything*. If you have time please give it a shot. I have successfully used it to download and install openssh from http://mirrors.rcn.net with WinNT 4.0SP5. With the previous setup snapshot that url caused a crash. Also it looks like the new setup has a nice feature and can update in use binaries (I was using ssh at the time of the successful update above). However I can't find the registry entry that is used to move the new ssh.exe on top of the old one at (re-)boot time. So exactly how does the new install do its magic? I had gotten used to having updates on running packages fail, might it be a good idea to offer an option Update running programs (requires reboot) in one of the screens. That way we could safely update the packages we aren't using without having to reboot. Actually this begs the question, what happened when install failed due to in use binaries? Did it clean up after itself and reinstall the old files, or was I left with a mix of file versions after the failed update? I never had any problems after a failed update, so I always assumed that it cleaned up and backed out the updated files. Was I wrong? -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. -- 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/
