Small wingdi.h bug
The following prototype in wingdi.h should not have the CONST qualifier for COLORREF. Perhaps it was mis-copied from the wglSet... function? WINGDIAPI int WINAPI wglGetLayerPaletteEntries(HDC, int, int, int, CONST COLORREF *) -- 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/
Installer bug with symlinks
The installer can make a directory for new files even if there is already an existing directory symlink of the same name. I discovered the problem when upgrading where I had a custom X11 build. I moved /usr/X11R6 to /usr/X11R6.dist, and made the symlink /usr/X11R6 -> /usr/X11R6.build. When updating some packages with files in /usr/X11R6, I ended up with new files installed in /usr/X11R6 while the symlink name of the same name still existed. Joe Krahn -- 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/
Cygwin processes getting stuck on max CPU usage; XP SP2 problem?
I use SysInternal's Process Explorer a lot. After installing XP SP2, if I browse Cygwin processes in ProceExp, I can no longer get the list of loaded DLLs, and they get stuck at max CPU usage along with csrss.exe. The CygWin processes continue working OK, but the whole system (obviously) gets slowed down. I noticed that csrss.exe is new with XP SP2. Maybe it's involved in querying process information, and does not play well with CygWin? Thanks, Joe Krahn -- 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/
Path processing bug
Cygwin will accept the path "dir/../file" as being the same as "file", regardless of whether "dir" exists. Apprently, someone decided that a simple path-trimming rule would speed things up, but it is wrong. For example, it breaks building of xedit/lisp, where "lisp/../xedit.h" is not the same as "xedit.h". This occurs from bash and tcsh, so it must be in some low-level unix-to-win32 path name processing. Joe Krahn Cygwin Configuration Diagnostics Current System Time: Sun Aug 21 17:35:58 2005 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\home\krahn\bin C:\Cygwin\usr\local\bin C:\Cygwin\usr\local\bin\netpbm C:\Cygwin\sbin C:\Cygwin\usr\sbin C:\Cygwin\bin C:\Cygwin\bin C:\Cygwin\usr\X11R6\bin C:\Cygwin\lib\subversion\bin C:\bin C:\windows C:\windows\system32 D:\DX9.0_Feb2005_SDK\Utilities\Bin\x86 C:\Program Files\Microsoft Visual Studio .NET\Vc7\bin C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE C:\Program Files\Microsoft Visual Studio .NET\Common7\Tools .\ Output from C:\Cygwin\bin\id.exe (nontsec) UID: 1007(krahn) GID: 513(None) 0(root) 513(None)544(Administrators) 545(Users) 1008(Debugger Users) Output from C:\Cygwin\bin\id.exe (ntsec) UID: 1007(krahn) GID: 513(None) 0(root) 513(None)544(Administrators) 545(Users) 1008(Debugger Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS CYGWIN = `tty notitle glob ntsec' HOME = `/D/krahn' PWD = `/D/krahn/x-devel/xc' USER = `krahn' MAKE_MODE = `unix' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\krahn\Application Data' CLASSPATH = `"C:\Program Files\Java\j2re1.4.1_02\lib\ext\QTJava.zip"' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DEVEL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' FP_NO_HOST_CHECK = `NO' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\krahn' INCLUDE = `C:\Program Files\Microsoft Visual Studio .NET\VC7\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio .NET\VC7\INCLUDE;C:\Program Files\Microsoft Visual Studio .NET\VC7\PlatformSDK\include\prerelease;C:\Program Files\Microsoft Visual Studio .NET\VC7\PlatformSDK\include;C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\include;C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\include\;C:\DXSDK\Include' LIB = `C:\Program Files\Microsoft Visual Studio .NET\VC7\ATLMFC\LIB;C:\Program Files\Microsoft Visual Studio .NET\VC7\LIB;C:\Program Files\Microsoft Visual Studio.NET\VC7\PlatformSDK\lib\prerelease;C:\Program Files\Microsoft Visual Studio .NET\VC7\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\lib;C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Lib\;C:\DXSDK\Lib' LOGONSERVER = `\\DEVEL' NUMBER_OF_PROCESSORS = `1' OPENSSL_CONF = `C:\OpenSSL\bin\openssl.cnf' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0207' PROGRAMFILES = `C:\Program Files' PS5ROOT = `C:\Program Files\PhotoSuite\' QTJAVA = `"C:\Program Files\Java\j2re1.4.1_02\lib\ext\QTJava.zip"' SESSIONNAME = `Console' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' USERDOMAIN = `DEVEL' USERNAME = `krahn' USERPROFILE = `C:\Documents and Settings\krahn' VSCOMNTOOLS = `"C:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\"' WINDIR = `C:\WINDOWS' _NT_SYMBOL_PATH = `SRV*D:\websymbols*http://msdl.microsoft.com/download/symbols' TERM = `xterm' COLORFGBG = `0;default;15' DISPLAY = `:0' WINDOWID = `6829568' COLORTERM = `rxvt-xpm' HOSTTYPE = `i386' VENDOR = `intel' OSTYPE = `posix' MACHTYPE = `i386' SHLVL = `1' LOGNAME = `krahn' GROUP = `None' HOST = `Devel' MANPATH = `:/usr/ssl/man:/usr/X11R6/man:/home/krahn/man:/home/krahn/perl/share/man:/home/krahn/Prog/toymd/ma/man' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' XCURSOR_CORE = `1' RSYNC_RSH = `ssh' CVS_RSH = `ssh' TAPE_OPTIONS = `--rsh-command=ssh' PAGER = `more' TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2' 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 Solutio
Re: Path processing bug
Eric Blake wrote: Cygwin will accept the path "dir/../file" as being the same as "file", regardless of whether "dir" exists. Apprently, someone decided that a simple path-trimming rule would speed things up, but it is wrong. For example, it breaks building of xedit/lisp, where "lisp/../xedit.h" is not the same as "xedit.h". This occurs from bash and tcsh, so it must be in some low-level unix-to-win32 path name processing. I've raised the issue of this bug in the past, and the response was that fixing it would likely slow down the normal case. I too would like to see it fixed, because it is contrary to POSIX. Well, it is obvious that supporting an invalid path is just plain wrong, and not a matter of opinion. However, I just checked in a DOS prompt and found that DOS/Windows allows removal of "/..". So, the real bug apparently comes from MS (big surprise?) I can see where path validation could be a significant slow-down, but "dir/.." is not part of most path names, so doing it 'right' should have a minimal performance impact. Joe Krahn -- 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/
File permission hassles on Vista
I have been running Cygwin on Vista. The way that file attributes are handled are causing problems. Cygwin appears to add attributes for 'Everyone' and a 'None' user to handle world and group POSIX attributes. On Vista, these attributes give the file a 'shared' property, which adds a shared file overlay on the GUI icons. If you try to manipulate files from the Windows GUI, things become VERY slow. It can take minutes just to move just a few files. It seems that the system is trying to keep track of shared files, and gets confused about files made shared by Cygwin. Maybe it is the indexing service? I am guessing that Cygwin developers just are not using Vista yet, because I have seen very little discussion of this problem. Until this problem is resolved, an easy fix might be to avoid adding the extra attributes groups as long as they have no permissions. A Vista user can set umask to 077, and avoid making those attribute groups. Another quick work-around would be to have a command-line tool to strip out the extra permission attributes. Is there a tool in cygwin that can manipulate win32 file attributes? I thought maybe 'chatter' would do it, but those attributes are apparently independent of Win32 attributes. If Cygwin doesn't have anything like this, I think it would be a good Win32 utility to include (i.e. sort of like regtool). Thanks, Joe Krahn -- 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/