Re: [ITP] talkfilters-3.8.1-1
On 11/11/2009 03:30, Yaakov (Cygwin/X) wrote: On 10/11/2009 03:38, Corinna Vinschen wrote: You didn't say in which stable Linux distro this package is available. Without that info, your package needs five votes from other maintainers. +1 Packaging looks good. I'm just wondering why all the executables are linked statically against libtalkfilters, rather than being linked against cygtalkfilters-1.dll. Don't eat your own dog food? ;) That's how upstream made the package, no fault of OP. (Cygwin Ports has had talkfilters for a while, as libtranslate uses it.) Yaakov Ping. Any other votes?
Re: [ITP] talkfilters-3.8.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Yaakov (Cygwin/X) on 11/10/2009 12:30 PM: On 10/11/2009 03:38, Corinna Vinschen wrote: You didn't say in which stable Linux distro this package is available. Without that info, your package needs five votes from other maintainers. +1 +1 from me - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr9VgYACgkQ84KuGfSFAYAtbwCgrRVXzg/N8vqSfVV0sPiJue1H L4sAoMZhCD5h3nT/qbveiIx3Nu1WgsVn =8u99 -END PGP SIGNATURE-
Re: [ITP] talkfilters-3.8.1-1
Ping. Any other votes? +1 from me. Chris -- Chris Sutcliffe http://emergedesktop.org
Re: [ITP] talkfilters-3.8.1-1
Ping. Any other votes? +1 Cheers, Peter -- They are in the crowd with the answer before the question. Why do you dislike Jeopardy?
Re: Cygwin/x window no longer appears
On Thu, Nov 12, 2009 at 11:16 PM, Olivia Cheronet cheronetoli...@yahoo.com wrote: Hello! I have recently started to work with Cygwin/X. Until now, I have been starting Cygwin/X by using startxwin.bat in the Cygwin bash shell. Everything seemed to be working fine. However, it has now stopped working... When I type startxwin.bat in the Cygwin shell, the normal startxwin.bat - starting on Windows NT/2000/XP/2003 appears. Yet, the window which used to appear no longer does. I am really not too sure what to do about this, given that I have not (consciously!) modified anything. I have installed Cygwin (and Cygwin/x) very recently, and have tried to reinstall the latter using Cygwin's setup.exe, but to no effect. I assume it's the terminal window (xterm) that does not show up. Does the X server start up? Check if the little X in the system tray is present, and stays when you put the mouse over it . If not, you need to check /var/log/XWin.*.log; there may be some error message there. (Best to delete it and then try startxwin.bat) Another test is to start a cmd.exe and run startxwin.bat from there. Are there any error messages from running startxwin.bat ? Does startxwin.bat really try to start the xterm? Maybe it got commented out (that's what I do with my startxwin) Hope this helps somewhat, Csaba -- Life is complex, with real and imaginary parts -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
// Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. Well. I took the advice and converted both FAT32 systems (one for 1.5 and one for 1.7) to NTFS. I quite like some of the file management consequences - e.g. chkdsk output, more efficient use of space - but working within Cygwin I'm not a happy bunny. I am sure that in many parallel universes the step you have advised results in huge benefits, but so far I can only report detriment to [1] use and [2] understanding. (I know [1] that requests/ complaints/ comments should not be too user-specific and as for [2] I'm really just hanging myself out to dry. But here goes ...) I operate both Cygwins 1.5 and 1.7 on a partitioned portable drive hooked up to different machines at different times. After changing to NTFS I find statements of folder permissions completely incomprehensible e.g. the + in drwxrwxrwx+; also that they do not alter after chmod instructions in the way I was expecting; that there are MANY additional user names and group names including ?? ; that files I worked on on Machine 1 now produce Permission denied when I try to work on them on Machine 2 All right, all of the above merely make manifest a complete lack of understanding of permissions, privileges, rights, etc. But it is after all my mobile drive, and every file on it was put there by me, is owned by me in some sense, and I ought to be able to do stuff. Finally (and I have tried to search for a solution) I alias ls as ls --color and had some lovely rxvt* xterm* and gnuplot* color schemes set up in ~/.Xdefaults. Now the rxvt* and xterm* color schemes have been lost (to be replaced by, I assume, some standard set, with a particularly horrid colour combination for directories (fg blue bg green). Confusingly, realised gnuplot* colors are still as set in .Xdefaults. Is there a way I can recover what I want for rxvt and xterm (maybe by putting the instructions into a different file). I think I will revert to FAT32 partitions and maybe put up with a working if not current XWin in 1.7. Like my experience with mobile phones, there is a threshold of sophistication beyond which I am just plain incapable of making progress, and the conversion of FAT32 to NTFS seems to have crossed that threshold for me with its unintended (or unexpected anyway) consequences. It is a marvellous advance in security I am sure (and I am very appreciative that Corinna and Jon took this up and responded to me) but I guess it just isn't for me. Thank you. If meanwhile you can point me somewhere for a solution to the lost colour schemes, I would be very grateful. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Running Java application with drag and drop support in cygwin
On 30/10/2009 09:06, Dees wrote: Your reply is much appreciated Jon. I will try to be more specific about the problem in further mails. On Thu, Oct 29, 2009 at 8:11 PM, Jon TURNEYjon.tur...@dronecode.org.uk wrote: On 28/10/2009 05:57, Dees wrote: I have developed a Java application involving jTree with extensive drag and drop support, which runs correctly in my Linux box. However, when I switch to a windows box and access the same Linux box using cygwin x-server, the drag and drop in jTree stops working. Interestingly, rest of the application still works fine. After analyzing a bit I found that x-server is able to recognize the drag event but fails to recognize a drop event. Details? OS : Suse Linux Enterprise Server 10 (i586) Version : 10 Patch level : 3 Other version information: Java : JDK 5 Cygwin setup-version: 2.573.2.3 Also tried using Xming 6.9.0.31 ssh same Linux setup from Windows, but that also doesn't solve the problem. Is there any setting, which should be done prior to running the Java swing applications? Here is a sample code which behaves in exactly same way. http://www.java2s.com/Code/Java/Swing-JFC/TreeDragandDrop.htm I have no idea how to use that java code to reproduce the problem you are seeing. Using the above java code in Linux: 1. Download and Install Java Development Toolkit on your Linux box (Java sun download site: http://java.sun.com/javase/downloads/index.jsp), if you do not have it already. 2. Save the sample code in the above link with the file name TreeTester.java, say in /home/user/ 3. Navigate to TreeTester.java from shell, and compile the java code: # cd /home/user/ # /usr/java/jdk1.5.0_14/bin/javac TreeTester.java Ignore any warnings of deprecated APIs. 4. This will create a few .class files in /home/user/ directory. Final step is to run the Java code, using: # /usr/java/jdk1.5.0_14/bin/java -classpath . TreeTester This will open up a GUI, with a jTree each on left and right pane. You can drag and drop any of the leaf nodes from one jTree to the root node of the other jTree and this should add a new node in the other jTree. You will get messages on console for the operations being performed. Now ssh the same box using cygwin/xming from any other windows box, and run the application using command in step 4. You should be able to drag (a small icon will come under cursor indicating that something is being dragged) but when you will drop it, the new node would not be added to the tree. Thats where lies my problem!!! Thanks for the test case and instructions, this makes it much easier for me to try it out. However, this testcase and your jar archive both work fine for me (using Xserver 1.7.1-3)! May be my problem is related to some setting. Though, not sure. Has anybody come across something similar? What should be done then? Please let me know. No it's probably a bug in Cygwin/X. But you're going to need to be a lot more specific about the problem before any progress can be made on fixing it. Also, putting some debug messages in the code lets me conclude that it's the drop event which is not being recognized, as the main control never reaches there. There is not really any drop event, as far as the X server is concerned, just mouse click and motion events, which are passed on to you application (which has a framework to interpret them as dragging and dropping an item). Now having a better idea of the problem, it seems less likely it is an Xserver bug at all. The only Xserver cause I can think of would be if it was somehow not sending the correct events to your applications window, which you could test using xev -id your applications window id (you can use xwininfo to find the window id) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
On 11/12/2009 10:14 PM, Ken Brown wrote: Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion [...] It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Never mind. I found the answer in a different thread: http://cygwin.com/ml/cygwin-xfree/2009-11/msg00085.html The workaround is to install the font-isas-misc, font-jis-misc, and font-daewoo-misc packages. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Automatically positioned mouse movements are off target
On 24/08/2009 23:05, Brian Sheppard wrote: I installed Cygwin/X (latest version, according to the Cygwin installer) on my laptop. I use Putty with X11 forwarding to connect to a Red Hat Linux system. I start the X windows server on my laptop using startxwin.bat as installed. After logging in to the Red Hat system, I execute gnome-session, and the gnome desktop shows on my Windows desktop. So far, so good. I am testing a Java application using a tool called Abbot. Abbot launches your Java Swing app within Abbot’s JVM. Abbot reads the coordinates of Swing components from internal Java objects, and then issues mouse and keystroke commands to simulate user actions according to a script. My observation is that the mouse clicks are off target. Specifically, Abbot is aiming to hit the exact center of each component, but it misses either high or low. (Left and right centering seem fine.) The amount of the miss has something to do with my Task Bar. When the Windows Task Bar is locked at top, then the clicks miss below (i.e., lower on the screen) the intended component. When the Task Bar is docked to the right, left, or bottom, or if it is at the top and set to auto-hide then mouse clicks miss above the intended component. Thanks for the problem report. I did some testing against Xserver 1.7.1 with xevent [1] and xdotool [2] to position the mouse pointer, but I wasn't able to reproduce the behaviour you are seeing. I really have no idea how to get started using abbot to reproduce the problem you see, a simple test case would help a lot here. [1] http://www.isv.uu.se/~ziemann/xevent/ [2] http://www.semicomplete.com/projects/xdotool/ -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: checkX problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of Lothar Brendel Could you please clarify an issue here? (Sorry, it seems, I wronged to ``run'' in the previous posts.) In a Windows command prompt (being somewhere on C:) I put the line \cygwin\bin\run -p /usr/bin sleep -wait 5 into a file ``dosleep.bat''. Executing that BAT-script (w/o any wrapper), it *does* sleep. Typing that very line directly at the prompt lets ``run'' return immediately, though. Can you confirm this behaviour? I can confirm that without testing (so I'm probably chomping foot here...). The sleep is holding the console open after run quits. This comes under the console programs must have a console heading. It takes a bit ti get used to, but you'll get it soon. Looking forward to reading your patches to address any of these problems. It shouldn't be too hard to add an option to checkX to make it retry if ECONNREFUSED. This would have to manually track the elapsed time for each attempt, charging against the specified -t waittime. Another possibility would be an option ``-n'' to specify the number of retries. GAH! No, that's just lame. Just spawn/fork a sleep-then-interrupt-daddy thread/process, set up a SIGINT handler that exits with an error, loop connection attempts until successful, check X, kill child, exit with success. That enforces both types of timeout. HTH, Mike
src/winsup/cygwin ChangeLog net.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-11-13 12:35:53 Modified files: winsup/cygwin : ChangeLog net.cc Log message: * net.cc (fdsock): Fill _rmem and _wmem with valid values returned from getsockopt if setsockopt with desired values failed. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4718r2=1.4719 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/net.cc.diff?cvsroot=srcr1=1.264r2=1.265
src/winsup/w32api ChangeLog include/winnt.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-11-13 21:36:34 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winnt.h Log message: 2009-11-09 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/winnt.h (PROCESS_SUSPEND_RESUME): Define. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.997r2=1.998 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winnt.h.diff?cvsroot=srcr1=1.128r2=1.129
src/winsup/w32api ChangeLog include/winuser.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-11-13 23:29:26 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winuser.h Log message: 2009-13-09 Jan Nijtmans nijtm...@users.sourceforge.net * include/winuser.h (SendMessageTimeoutA, SendMessageTimeoutW): Correct definition. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.998r2=1.999 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winuser.h.diff?cvsroot=srcr1=1.128r2=1.129
src/winsup/w32api ChangeLog include/winerror.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-11-13 23:58:58 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winerror.h Log message: 2009-13-09 Jacky Lai crazyja...@users.sourceforge.net * include/winerror.h: Fix typos in macro names. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.999r2=1.1000 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winerror.h.diff?cvsroot=srcr1=1.15r2=1.16
src/winsup/w32api ChangeLog include/wininet.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-11-14 00:45:36 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: wininet.h Log message: 2009-13-09 Robert Moerland rjmoerl...@users.sourceforge.net * include/wininet.h (NTERNET_CACHE_ENTRY_INFOW): Correct definition. (DeleteUrlCacheEntryW, DeleteUrlCacheEntryA): Define. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1000r2=1.1001 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/wininet.h.diff?cvsroot=srcr1=1.15r2=1.16
src/winsup/w32api ChangeLog include/wincon.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-11-14 00:50:50 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: wincon.h Log message: 2009-13-09 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/wincon.h (AttachConsole): Correct guard. Thanks to Alexander Shaduri for report. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1001r2=1.1002 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/wincon.h.diff?cvsroot=srcr1=1.13r2=1.14
src/winsup/mingw ChangeLog include/io.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-11-14 00:54:58 Modified files: winsup/mingw : ChangeLog winsup/mingw/include: io.h Log message: 2009-11-13 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/io.h (_open_osfhandle): Correct definition. Thanks to Alexander Shaduri for the information. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.453r2=1.454 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/io.h.diff?cvsroot=srcr1=1.21r2=1.22
Can you clone entire cygwin setup from one pc to another
I would like to clone the cygwin setup from one pc to another. Looking at the registry, it appears that at least in my case there are only a few registry entries with the text cygwin in them, including the %path% and several entries corresponding to the services I have set up (rsyncd, sshd, XWin). There might be one or 2 others I am missing. Conceptually, it seems that it would be sufficient to just copy over the C:\cygwin folder (plus my home directory) and to clone the registry entries. One would be advised of course to use rsync with the -H flag to make sure hard links are preserved. But is there something I am missing? Has anybody packaged up a script to copy over the registry entries? (that would be the part I worry most since I wouldn't want to miss any entries or corrupt anything) Are there any hidden persistent security entries? I'm sure this has been addressed before but my googling only led to posts about people trying to copy over the tar packages but I saw little about cloning the full cygwin installation. I want to do this since it could be a *lot* faster than first installing the packages (that's not the problem) and then painstakingly redoing all my customizations that accumulate over time. -- View this message in context: http://old.nabble.com/Can-you-clone-entire-cygwin-setup-from-one-pc-to-another-tp26333733p26333733.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can you clone entire cygwin setup from one pc to another
I guess the other thing to worry about would be ACL entries. If there are any, I could solve that with getfacl/setfacl assuming that the ACL changes were addressable by getfacl/setfacl. And if not I could always use 'subinacl' to just clone the entire ACL structure of the C:\cygwin tree. -- View this message in context: http://old.nabble.com/Can-you-clone-entire-cygwin-setup-from-one-pc-to-another-tp26333733p26333860.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7 file permissions changes
On Nov 12 10:12, Eric Benson wrote: Recently I installed Windows 7 and Cygwin 1.7 from scratch and rebuilt all of the pieces of my system using the latest versions of all components. The encoder process is now failing because it is unable to remove the directory that was created by the Autoit script. The Cygwin process can read files created by the Windows process just fine, but it cannot create new files in that directory, nor can it delete any files or directories created by the Windows process. I have complete control of all directory and file creation on both sides of the Cygwin/Windows divide. Is there something I can do on either side so that the directory I create in Windows (using Autoit's DirCreate function) can be modified and deleted by Cygwin's Unix API? Without more details I hazard a guess: The Windows process creates the directory without permissions for you to delete the directory or files in that directory and you're running under UAC. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can you clone entire cygwin setup from one pc to another
On Nov 13 01:44, aputerguy wrote: I guess the other thing to worry about would be ACL entries. If there are any, I could solve that with getfacl/setfacl assuming that the ACL changes were addressable by getfacl/setfacl. And if not I could always use 'subinacl' to just clone the entire ACL structure of the C:\cygwin tree. For exakt cloning including ACLs, I would suggest to use robocopy. Yes, it's a native tool, but it's sort of a swiss army knife to do exactly that job. You don't need to copy the registry entries. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
On Nov 12 17:23, Eliot Moss wrote: I went ahead and wrote a little program that narrows down the rsync problem to a dup2 call. The program: creates two pipes (for talking to a child process), forks the child, and the child tries to dup2 the pipe fds to its stdin and stdout. If it wins (which it doesn't), it will then run sleep for 5 seconds and quit. The parent closes some fds it doesn't need and waits for the child, then quits. I attach the program in question, and strace output. Cheers -- Eliot Moss Thanks for the testcase. However, the problem is that I can't reproduce any problem using your testcase. I ran it on Windows XP SP3, Server 2008 SP1, and Windows 7. The result is this, just with changing PIDs: $ ./a_test pid = 3272, fin = 5, fout = 4 wait got 0 I assume you see some error, but you didn't explicitely write what error you see. The strace output shows an error when closing a socket, which is that dreaded Winsock error 10038, socket operation on non-socket. The reason why this operation fails must be something on your machine. I'm just not sure how we can find out what that is, and how to avoid the error then. Simply ignoring error 10038 in close() doesn't sound like a terribly good idea... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
On Nov 12 17:23, Eliot Moss wrote: 41 320784 [main] a_test 5244 fhandler_socket::dup: here 57 320841 [main] a_test 5244 fhandler_base::dup: in fhandler_base dup 39 320880 [main] a_test 5244 fhandler_base::dup: dup() failed, handle 35C, Win32 error 6 37 320917 [main] a_test 5244 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-64/winsup/cygwin/fhandler.cc:1151 windows error 6 41 320958 [main] a_test 5244 geterrno_from_win_error: windows error 6 == errno 9 Duh! Of course this is the actual error you see. DuplicateHandle fails with ERROR_INVALID_HANDLE. The same problem occurs in close(), but on the Winsock level where closesocket() returns with error 10038. Ultimately this means that every socket handle is not recognized as a handle at all in the child process for some unknown reason. And why does that happen on some machines only, but not on others? Is that a BLODA problem? Did you seriously check all possible BLODAs? http://cygwin.com/acronyms/#BLODA http://cygwin.com/1.7/faq/faq.using.html#faq.using.bloda I just searched for this problem via google and it turns out that Cygwin isn't the only software having this problem. The second hit was already quite interesting: http://www.vadvbbs.com/products/vadv32/support/index.php#What_does_Invalid_Socket_Handle_mean Anyway, it would be nice if we could avoid this problem even if a BLODA is running. There are three possible solutions which come to mind and which we can test. May I send you an URL to an experimental Cygwin DLL via PM? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
Corinna Vinschen wrote: On Nov 12 17:23, Eliot Moss wrote: I went ahead and wrote a little program that narrows down the rsync problem to a dup2 call. The program: creates two pipes (for talking to a child process), forks the child, and the child tries to dup2 the pipe fds to its stdin and stdout. If it wins (which it doesn't), it will then run sleep for 5 seconds and quit. The parent closes some fds it doesn't need and waits for the child, then quits. I attach the program in question, and strace output. Cheers -- Eliot Moss Thanks for the testcase. However, the problem is that I can't reproduce any problem using your testcase. I ran it on Windows XP SP3, Server 2008 SP1, and Windows 7. The result is this, just with changing PIDs: $ ./a_test pid = 3272, fin = 5, fout = 4 wait got 0 I assume you see some error, but you didn't explicitely write what error you see. The strace output shows an error when closing a socket, which is that dreaded Winsock error 10038, socket operation on non-socket. The reason why this operation fails must be something on your machine. I'm just not sure how we can find out what that is, and how to avoid the error then. Simply ignoring error 10038 in close() doesn't sound like a terribly good idea... Thank you for looking more closely! The actual failure is earlier in the strace output, I think. If you look for dup2 you see that the first dup2 call fails on my machine. Can this fail because of some permissions thing? I have UAC set to Never notify. I am logged in as me (Eliot), and I have Administrator rights. I get the same result from a_test if I run bash as Administrator and run a_test. Here is sample program output for me: pid = 9064, fin = 5, fout = 4 error: first dup2 -1 9 wait got 65280 If I understand correctly, the wait code says the child terminated with result -1, which corresponds with what the code does when that dup2 fails. Any suggestions for the next step in debugging this? I can certainly accept that it's something about my machine, but I am rather at a loss of where to look ... Regards -- Eliot -- 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: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
On Nov 13 07:31, Eliot Moss wrote: Oh, and in terms of BLODA, my antivirus is Symantec with on-access scan OFF. I've not seen other issues with it. I do have Windows Defender -- perhaps it causes the popups. I'm not entirely clear how I can turn it off. It was not previously a problem ... I just switched on Windows Defender with realtime protection and it doesn't have any effect as far as a_test goes. It still works fine for me. Symantec could be a problem, even if on-access scan is switched off. It installs DLLs which hook into the OS and could have undesired side effects, like the one we're talking about. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
On Nov 13 07:29, Eliot Moss wrote: I can also report that the first time I run a_test, a Windows popup happens asking if I want to allow this program to access the network. I click Allow, but it seems not to be allowing. No, that has nothing to do with it. It's just the Windows firewall asking. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can you clone entire cygwin setup from one pc to another
On Nov 13 04:31, aputerguy wrote: Corinna VInschen writes: For exakt cloning including ACLs, I would suggest to use robocopy. Yes, it's a native tool, but it's sort of a swiss army knife to do exactly that job. You don't need to copy the registry entries. Thanks Corinna! When you say that I don't need to copy the registry entries, what do I do then to copy over the services? Uh, I was only thinking of the Cygwin-specific registry keys. Oh, and I'm only talking about Cygwin 1.7. For Cygwin 1.5 you have to duplicate the registry mount points using `mount -m'. For the service, you should reinstall them the official way using the config scripts. You can't just copy the service registry keys and expect the target SCM to know about them. SCM doesn't accept services which aren't installed via SCM, or at least are available when the system starts up. So, at least, If you really copy these registry entries, you must reboot the machine afterwards. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
Oh, and in terms of BLODA, my antivirus is Symantec with on-access scan OFF. I've not seen other issues with it. I do have Windows Defender -- perhaps it causes the popups. I'm not entirely clear how I can turn it off. It was not previously a problem ... Cheers -- E -- 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: Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]
Corinna Vinschen wrote: On Nov 12 17:23, Eliot Moss wrote: 41 320784 [main] a_test 5244 fhandler_socket::dup: here 57 320841 [main] a_test 5244 fhandler_base::dup: in fhandler_base dup 39 320880 [main] a_test 5244 fhandler_base::dup: dup() failed, handle 35C, Win32 error 6 37 320917 [main] a_test 5244 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-64/winsup/cygwin/fhandler.cc:1151 windows error 6 41 320958 [main] a_test 5244 geterrno_from_win_error: windows error 6 == errno 9 Duh! Of course this is the actual error you see. DuplicateHandle fails with ERROR_INVALID_HANDLE. The same problem occurs in close(), but on the Winsock level where closesocket() returns with error 10038. Ultimately this means that every socket handle is not recognized as a handle at all in the child process for some unknown reason. And why does that happen on some machines only, but not on others? Is that a BLODA problem? Did you seriously check all possible BLODAs? http://cygwin.com/acronyms/#BLODA http://cygwin.com/1.7/faq/faq.using.html#faq.using.bloda I just searched for this problem via google and it turns out that Cygwin isn't the only software having this problem. The second hit was already quite interesting: http://www.vadvbbs.com/products/vadv32/support/index.php#What_does_Invalid_Socket_Handle_mean Anyway, it would be nice if we could avoid this problem even if a BLODA is running. There are three possible solutions which come to mind and which we can test. May I send you an URL to an experimental Cygwin DLL via PM? Sure. I can also report that the first time I run a_test, a Windows popup happens asking if I want to allow this program to access the network. I click Allow, but it seems not to be allowing. I wrote a variant of a_test that, before it tries the dups, tries to have the parent send something to the child, have the child read it, write it back on the other pipe, and have the parent read it. Since it's nonlocking I/O, I had to put in retry loops and used sleep(1) in them, but on garden-flavor Unix it works. On cygwin on my box the parent writes but the child never gets the data. It's as if Windows has quarantined it, even though I said Allow! Regards -- Eliot -- 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 and Msys
Hi all, I installed Msys to test MingW and uninstalled them both. However now my HOME path is set to /cygdrive/c/msys/1.0/home and I can't get my home directory back. Any Ideas? Thanks, -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin and Msys
Quoting Ali Irfan Ustek alius...@gmail.com: Hi all, I installed Msys to test MingW and uninstalled them both. However now my HOME path is set to /cygdrive/c/msys/1.0/home and I can't get my home directory back. No idea as to why this has happened. But please have a look at /etc/profile. This file lists the various ways, and their order of precedence, of how HOME is set. Installing Msys or MingW may have altered one of the relevant settings. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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
emacs 23.1.1 macro behavior and name completion
Emacs 23.1.1 (Cygwin 1.7) stores spaces literally inside emacs macros instead of using the space as a name completion command. In the older emacs (Cygwin 1.5) this is not the case. The stored macro behaved exactly like the keystrokes were originally typed interactively. Is this a feature of the new emacs? Does this emacs version do the same thing on a native Linux PC? i.e., does this have anything to do with Cygwin itself? -- 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: emacs 23.1.1 macro behavior and name completion
On 11/13/2009 9:57 AM, Rockefeller, Harry wrote: Emacs 23.1.1 (Cygwin 1.7) stores spaces literally inside emacs macros instead of using the space as a name completion command. In the older emacs (Cygwin 1.5) this is not the case. The stored macro behaved exactly like the keystrokes were originally typed interactively. Is this a feature of the new emacs? Does this emacs version do the same thing on a native Linux PC? i.e., does this have anything to do with Cygwin itself? This almost certainly has nothing to do with cygwin. There have been many changes in emacs since version 21 (which you were using before), including changes in how completion is done and changes involving keyboard macros. Use the help and info facilities within emacs, or browse the NEWS files in /usr/share/emacs/23.1/etc/. Further questions on this should go to one of the emacs lists unless you find evidence that the issue is related to cygwin. Ken -- 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: emacs 23.1.1 macro behavior and name completion
Ken Brown wrote: On 11/13/2009 9:57 AM, Rockefeller, Harry wrote: Emacs 23.1.1 (Cygwin 1.7) stores spaces literally inside emacs macros instead of using the space as a name completion command. In the older emacs (Cygwin 1.5) this is not the case. The stored macro behaved exactly like the keystrokes were originally typed interactively. Is this a feature of the new emacs? Does this emacs version do the same thing on a native Linux PC? i.e., does this have anything to do with Cygwin itself? This almost certainly has nothing to do with cygwin. There have been many changes in emacs since version 21 (which you were using before), including changes in how completion is done and changes involving keyboard macros. Use the help and info facilities within emacs, or browse the NEWS files in /usr/share/emacs/23.1/etc/. Further questions on this should go to one of the emacs lists unless you find evidence that the issue is related to cygwin. Ken However! Given the various issues people have seen around the setting of LANG and the cygwin 1.7 changes in handling locale, I would also recommend looking into that. Try setting LANG=C and comparing with LANG=C.UTF-8 and LANG=en_US.UTF8 ... Ken is probably right, but this is easy to check. Regards -- Eliot Moss -- 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: ID command returns mkgroup
On 11/12/2009 07:07 PM, Larry Hall wrote: On 11/12/2009 06:47 PM, Dave Korn wrote: Larry Hall (Cygwin) wrote: On 11/12/2009 09:14 AM, dexter_mich...@emc wrote: Should my ID output be the same as when I log into a unix server here, or would it be different? My cygwin is running on a Windows workstation so maybe it is grabbing my AD groups as opposed to my NIS groups. The former. Cygwin operates on Windows to create a POSIXy environment on Windows. It's not a Linux/UNIX VM running on Windows. ITYM the latter. Grabbing the AD groups is exactly what is going on. (I'm inferring that Mike is in a heterogeneous environment with essentially separate user accounts on the Unix and Windows sides, based on YP/NIS and AD respectively.) Since we're in violent agreement about what was meant, I don't think it really matters however former refers to the first of two things mentioned. The latter refers to the second. Since Dexter mentioned AD first and NIS second, The former as I used it refers to the AD groups. The latter refers to the NIS groups. But subsequently looking around the web a bit and seeing all the confusion on how these terms should be used, it occurs to me that my response doesn't say much if the definition of the former is not clear. So I think your response does help in that regard, Dave. Why am I not surprised? :-) It's not the definition of former that's the problem, but failing to specify the antecedent. If you are answering the question (same as unix, or different?) the answer is the latter. If you are responding to the statement (AD groups as opposed to NIS groups) the answer is the former. --paulr
Re: Suggestion: Have setup.exe warn before upgrading 'cgywin' package itself
On Thu, Nov 12, 2009 at 02:46:12PM -0800, aputerguy wrote: Currently when upgrading the base 'cygwin' package, the installer only warns you midway through the installation after some files have been removed/replaced. If you have other cygwin processes running, you may be left in an incomplete state where you can't or don't want to kill the other cygwin processes leaving you stuck in the middle of install while you wait to be able to finish or kill the existing cygwin processes. Even worse, several core cygwin utilities are now broken (such as 'ps') due to the partial install. I have done this inadvertently a couple of times when 'cygwin' gets thrown in as a part of another intentioned download. Today I was left in an even odder state since I ran 'setup.exe' from a bash prompt -- leaving me in a catch-22 since if I kill the bash processes then I kill setup but I can't continue until I kill the bash processes... Why would doing a kill -9 on the bash process kill setup.exe? There is no reason for that to happen. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How to capture stderr of dos process running in bash shell??
I am trying to capture the error messages of 'subinacl.exe' (a dos program included with Windows 2003 toolkit) which I am running from a bash script. However both the stderr and stdout of the process seem to go to bash stdout since redirecting bash stderr (2) doesn't seem to have any effect. I assume this is because the dos process is running in a bash shell. Still, I was wondering whether there are any 'tricks' to somehow capture it. -- View this message in context: http://old.nabble.com/How-to-capture-stderr-of-dos-process-running-in-bash-shell---tp26341304p26341304.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to capture stderr of dos process running in bash shell??
On Fri, Nov 13, 2009 at 10:39:41AM -0800, aputerguy wrote: I am trying to capture the error messages of 'subinacl.exe' (a dos program included with Windows 2003 toolkit) which I am running from a bash script. However both the stderr and stdout of the process seem to go to bash stdout since redirecting bash stderr (2) doesn't seem to have any effect. I assume this is because the dos process is running in a bash shell. More likely it is writing to the console directly, rather like writing to /dev/tty on UNIX. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygrunsrv behaviour triggers Anti-Virus Program
Output of Kaspersky Anti-Virus 6.0 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Process is trying to inject into another process. This behavior is typical of some malicious programs (Invader) 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Quarantine action is selected 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Forced to terminate the process. 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE File quarantined. Output of Kaspersky Anti-Virus 6.0 -- 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: [OT] Re: No output on stdout
Also, you can check exit status from the shell by running echo $? after the command, which is a bit less trouble than using the debugger. The $? shell variable gets set to the status of the last command executed. (This is generic shell stuff, not cygwin-specific.) Of course. Why do I forget the basic stuff - back to the roots keeping it simple. Thx for the reminder. /F -- 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: [OT] Re: No output on stdout
On Fri, Nov 13, 2009 at 08:29:08PM +0100, Federico Hernandez wrote: ?Also, you can check exit status from the shell by running echo $? after the command, which is a bit less trouble than using the debugger. ?The $? shell variable gets set to the status of the last command executed. ?(This is generic shell stuff, not cygwin-specific.) Of course. Why do I forget the basic stuff - back to the roots keeping it simple. And, btw, in Cygwin 1.7 you will get an error rather than a silent exit. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygrunsrv behaviour triggers Anti-Virus Program
2009/11/13 Jacob Jacobson: Output of Kaspersky Anti-Virus 6.0 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Process is trying to inject into another process. This behavior is typical of some malicious programs (Invader) 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Quarantine action is selected 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Forced to terminate the process. 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE File quarantined. Output of Kaspersky Anti-Virus 6.0 Send that to Kaspersky. Cygwin isn't gonna be changed to work around that sort of crap. Andy -- 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
[BUG] fopen(..., a) does not seek to end of file until some write operation
Hii
Using ftell() after fopen(..., a) returns 0 even when the file open for
appending is not empty. AFAIK, it should return the size of the file.
Compile and run the attached program several times to see it happening.
Cheers,
- Salva
cygcheck.out
Description: Binary data
#include stdio.h
int main(int argc, char *argv[]) {
FILE *f = fopen(file.out, a);
fprintf(stderr, pos: %d\n, ftell(f));
fprintf(f, hello world\n);
fprintf(stderr, pos: %d\n, ftell(f));
fclose(f);
}
--
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: [BUG] fopen(..., a) does not seek to end of file until some write operation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Salvador Fandino on 11/13/2009 1:36 PM: Hii Using ftell() after fopen(..., a) returns 0 even when the file open for appending is not empty. AFAIK, it should return the size of the file. Not a bug. POSIX allows this behavior, and Linux does it as well. POSIX also allows BSD behavior of seeking to the end, although this is less friendly to reading back a file opened with fopen(...,a+). So portable programs can't expect either situation, and you MUST use fseek when opening for append if you expect a particular position. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr9xGoACgkQ84KuGfSFAYC8CACgtx1ZxOtKVaGF2xk2UHg+1B7c 7cUAniO/T6EOm0gxRRx/1wsCM6P2HXXl =xedo -END PGP SIGNATURE- -- 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: [BUG] fopen(..., a) does not seek to end of file until some write operation
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Salvador Fandino on 11/13/2009 1:36 PM: Hii Using ftell() after fopen(..., a) returns 0 even when the file open for appending is not empty. AFAIK, it should return the size of the file. Not a bug. POSIX allows this behavior, and Linux does it as well. POSIX also allows BSD behavior of seeking to the end, although this is less friendly to reading back a file opened with fopen(...,a+). So portable programs can't expect either situation, and you MUST use fseek when opening for append if you expect a particular position. however writing will always take place at the end of the file. Opening a file with append mode (a as the first character in the mode argument) shall cause all subsequent writes to the file to be forced to the then current end-of-file, regardless of intervening calls to fseek( ). rw - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr9xGoACgkQ84KuGfSFAYC8CACgtx1ZxOtKVaGF2xk2UHg+1B7c 7cUAniO/T6EOm0gxRRx/1wsCM6P2HXXl =xedo -END PGP SIGNATURE- -- 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 -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@saic.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [BUG] fopen(..., a) does not seek to end of file until some write operation
- Original Message From: Eric Blake e...@byu.net To: cygwin@cygwin.com; sfand...@yahoo.com Sent: Fri, November 13, 2009 9:41:14 PM Subject: Re: [BUG] fopen(..., a) does not seek to end of file until some write operation -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Salvador Fandino on 11/13/2009 1:36 PM: Hii Using ftell() after fopen(..., a) returns 0 even when the file open for appending is not empty. AFAIK, it should return the size of the file. Not a bug. POSIX allows this behavior, and Linux does it as well. In Linux (at least on the one I have installed, Ubuntu 9.10) ftell does not return cero but the EOF offset: sa...@leon:/tmp$ ./a.out pos: 0 pos: 12 sa...@leon:/tmp$ ./a.out pos: 12 pos: 24 sa...@leon:/tmp$ ./a.out pos: 24 pos: 36 Cheers, - Salva -- 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: [BUG] fopen(..., a) does not seek to end of file until some write operation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Salvador Fandino on 11/13/2009 1:55 PM: Not a bug. POSIX allows this behavior, and Linux does it as well. In Linux (at least on the one I have installed, Ubuntu 9.10) ftell does not return cero but the EOF offset: Ok, so a and a+ apparently behave differently in Linux. Submit a patch to newlib if it bothers you. Still, the point remains that this does not violate POSIX. Also, since the underlying open() is _required_ to be at offset 0 when opening a file for appending, it is actually _more_ syscalls if stdio seeks to the end of an append stream during fopen(), rather than waiting until the first write. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr9yz8ACgkQ84KuGfSFAYB5xQCfSJfFcEpkpFdiCQJ1WU1xFWHb UigAn05HDxKfozs7eFkMgxZ8PiBgJoHS =sfVV -END PGP SIGNATURE- -- 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: How to capture stderr of dos process running in bash shell??
Christopher Faylor sent the following at Friday, November 13, 2009 1:43 PM On Fri, Nov 13, 2009 at 10:39:41AM -0800, aputerguy wrote: I am trying to capture the error messages of 'subinacl.exe' (a dos program included with Windows 2003 toolkit) which I am running from a bash script. However both the stderr and stdout of the process seem to go to bash stdout since redirecting bash stderr (2) doesn't seem to have any effect. I assume this is because the dos process is running in a bash shell. More likely it is writing to the console directly, rather like writing to /dev/tty on UNIX. See also the Cygwin User's Guide: http://cygwin.com/cygwin-ug-net/using-effectively.html#id322908 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7 file permissions changes
Without more details I hazard a guess: The Windows process creates the directory without permissions for you to delete the directory or files in that directory and you're running under UAC. Yes, this turns out to be true. I disabled UAC entirely and now my program works. Is there a better way to share file and directory creation, modification and deletion between Cygwin processes and ordinary Windows processes, such that disabling UAC is not required? Some combination of umask and/or chmod on the Cygwin side with FileSetAttrib in Autoit (roughly equivalent to SetFileAttributes in the Windows API)? There is only one Windows user involved. As a Unix hacker I am somewhat mystified by this behavior. -- 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: Cygrunsrv behaviour triggers Anti-Virus Program
Andy Koppe wrote: 2009/11/13 Jacob Jacobson: Output of Kaspersky Anti-Virus 6.0 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Process is trying to inject into another process. This behavior is typical of some malicious programs (Invader) 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Quarantine action is selected 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Forced to terminate the process. 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE File quarantined. Output of Kaspersky Anti-Virus 6.0 Send that to Kaspersky. Cygwin isn't gonna be changed to work around that sort of crap. BLODA in full effect. It is designed to stop you running anything that behaves like forking, just in case what you were running wasn't meant to be doing that; therefore it is a crude and indiscriminate filter and must inevitably suffer false positives. The problem is that there's no easy way for a simple-minded computer program to tell the difference between suspicious process injecting itself into another, and legitimate user-directed application attempting to emulate posix fork semantics. It is unfortunate, but a lot of the things that Cygwin *has* to do are exactly like a lot of the things that some viruses do; hence we run up against the limits of heuristic behaviour blockers. cheers, DaveK -- 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: [BUG] fopen(..., a) does not seek to end of file until some write operation
Eric Blake wrote: According to Salvador Fandino on 11/13/2009 1:36 PM: Using ftell() after fopen(..., a) returns 0 even when the file open for appending is not empty. AFAIK, it should return the size of the file. Not a bug. POSIX allows this behavior, and Linux does it as well. POSIX also allows BSD behavior of seeking to the end, although this is less friendly to reading back a file opened with fopen(...,a+). So portable programs can't expect either situation, and you MUST use fseek when opening for append if you expect a particular position. I'm really confused; aren't you saying that there is exactly no difference between opening for append and just opening in ordinary r/w mode? I always thought the positioning of the write pointer immediately after open was the only possible difference there could be. cheers, DaveK -- 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: How to capture stderr of dos process running in bash shell??
aputerguy wrote: I am trying to capture the error messages of 'subinacl.exe' (a dos program included with Windows 2003 toolkit) which I am running from a bash script. However both the stderr and stdout of the process seem to go to bash stdout since redirecting bash stderr (2) doesn't seem to have any effect. I assume this is because the dos process is running in a bash shell. Still, I was wondering whether there are any 'tricks' to somehow capture it. It's not about whether it's running in one kind of shell or the other; what matters is whether it is running in a DOS console or a GUI-style thing like xterm or rxvt. In Cygwin GUI terminals, stdin and stdout are connected to pipes, rather than to a win32 console device, which does confuse some win32 applications. You should be able to work around it by running bash in a dos-style console instead of a GUI version, and making sure you do not have the 'tty' option set in your CYGWIN environment variable (since that has the effect of making even shells running in a console use pipes instead of talking to the console, which is where the confusion arises). cheers, DaveK -- 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: Cygrunsrv behaviour triggers Anti-Virus Program
On Fri, Nov 13, 2009 at 8:05 PM, Dave Korn wrote: Andy Koppe wrote: 2009/11/13 Jacob Jacobson: Output of Kaspersky Anti-Virus 6.0 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Process is trying to inject into another process. This behavior is typical of some malicious programs (Invader) 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Quarantine action is selected 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE Forced to terminate the process. 11/13/2009 1:03:09 PM C:\WIN\CYGWIN\BIN\CYGRUNSRV.EXE File quarantined. Output of Kaspersky Anti-Virus 6.0 Send that to Kaspersky. Cygwin isn't gonna be changed to work around that sort of crap. BLODA in full effect. It is designed to stop you running anything that behaves like forking, just in case what you were running wasn't meant to be doing that; therefore it is a crude and indiscriminate filter and must inevitably suffer false positives. The problem is that there's no easy way for a simple-minded computer program to tell the difference between suspicious process injecting itself into another, and legitimate user-directed application attempting to emulate posix fork semantics. It is unfortunate, but a lot of the things that Cygwin *has* to do are exactly like a lot of the things that some viruses do; hence we run up against the limits of heuristic behaviour blockers. cheers, DaveK -- The real question is whether or not Kaspersky will let you exclude specific processes from this sort of inspection. If so, just exclude cygrunsrv.exe. I routinely have to do this depending on what AV I am running. Heck, if I run the whole Comodo Security Suite, I get pages of prompts every time I run setup.exe and it changes files around. It's all hey, bash is trusted, but it is doing something it didn't do yesterday and it has a different checksum. Security is pain. -Jason -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
