Re: [RFU] libgcrypt-1.4.1-1
On Apr 28 23:30, Gergely Budai wrote: http://home.arcor.de/thuffir/cygwin/libgcrypt/libgcrypt-1.4.1-1-src.tar.bz2 \ http://home.arcor.de/thuffir/cygwin/libgcrypt/libgcrypt-1.4.1-1.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[PACKAGING ERROR] subversion-1.4.5-2
Oooh, only just noticed this one: -snip- /artimi/software/firmware $ cygcheck -c subversion Cygwin Package Information Package VersionStatus subversion 1.4.5-2OK -snip- /artimi/software/firmware $ cygcheck /bin/svn.exe | tr -d ' ' |sort | uniq C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\ntdll.dll C:\cygwin\bin/svn.exe C:\cygwin\bin\cygapr-1-0.dll C:\cygwin\bin\cygaprutil-1-0.dll C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cygcrypto-0.9.8.dll C:\cygwin\bin\cygdb-4.2.dll C:\cygwin\bin\cygexpat-0.dll -snip- http://www.mirrorservice.org/sites/sourceware.org/pub/cygwin/release/subversio n/setup.hint sdesc: A version control system ldesc: Subversion is a version control system that aims to be a compelling replacement for CVS in the open source community category: Devel requires: cygwin libaprutil1 libapr1 libdb4.2 libneon26 expat libintl8 -snip- The requires: line is wrong. That should say libexpat0, which contains the library DLL, not expat, which is the main executable. cheers, DaveK -- Can't think of a witty .sigline today
[RFU] atool-0.34.0-2
This release corrects a packaging error, that caused the man pages for most of the atools to be unavailable. Please upload. Thanks, Andrew. wget \ http://home.comcast.net/~andrex/cygwin/atool/atool-0.34.0-2.tar.bz2 \ http://home.comcast.net/~andrex/cygwin/atool/atool-0.34.0-2-src.tar.bz2
Re: [RFU] atool-0.34.0-2
On Apr 29 12:07, Andrew Schulman wrote: http://home.comcast.net/~andrex/cygwin/atool/atool-0.34.0-2.tar.bz2 \ http://home.comcast.net/~andrex/cygwin/atool/atool-0.34.0-2-src.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PACKAGING ERROR] subversion-1.4.5-2
Dave Korn wrote: Oooh, only just noticed this one: subversion 1.4.5-2OK requires: cygwin libaprutil1 libapr1 libdb4.2 libneon26 expat libintl8 The requires: line is wrong. That should say libexpat0, which contains the library DLL, not expat, which is the main executable. True enough. Mind you, when I wrote that requires line, expat was a monolithic package and libexpat0 didn't exist, so I'm not feeling particularly bad about it. Max. signature.asc Description: OpenPGP digital signature
Putting my packages up for adoption
Greetings all, I've been using Linux exclusively at work for over a year. Today I've started dual-booting my primary machine to Linux too. I'm no longer going to be using Windows on a daily basis, so I don't think I'll be able to do an adequate job of package maintenance in the future. Accordingly I'm putting my packages up for adoption: * apache2 * apr1 aprutil1 * doxygen * expat * neon * patchutils * sqlite3 * subversion * swig I'll be keeping an eye on the list, if people want to ask any questions about the packages, and until adopters can be found I may still manage an update or two. Farewell, of sorts, and thanks everyone for helping make Windows a nice place to be the past many years! Max. signature.asc Description: OpenPGP digital signature
Re: Putting my packages up for adoption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Max Bowsher on 4/29/2008 4:47 PM: | Accordingly I'm putting my packages up for adoption: | | * patchutils I use this enough to warrant adopting it. I'll post an ITA soon (although since it hasn't changed upstream, I'm not sure what the ITA would do other than repackage with cygport)... | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Farewell, and thanks for your efforts. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkgX9tgACgkQ84KuGfSFAYDKxQCfXoUVIooEdM8hDCmLqI48H0T+ xE8AoMDmvee0IXRKE4/wnX6yOXR3uste =MO0N -END PGP SIGNATURE-
Can't build cygwin X server : directory program/xrx is missing
I'm trying to rebuild X server (XWin.exe) from the source tree xorg-x11 6.8.99.901-1 (last stable version) when I run 'make', I get those errors $ make World ... make[3]: Leaving directory `/usr/src/xc/programs/xrefresh' cleaning in programs/xrx... make: Entering an unknown directory make: *** xrx: No such file or directory. Stop. make: Leaving an unknown directory make[2]: *** [clean] Error 2 make[2]: Leaving directory `/usr/src/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/usr/src/xc' make: *** [World] Error 2 The directory /usr/src/xc/programs/xrx is missing The source package of xorg-x11-bin (which contains xrx.exe) doesn't contain this directory Where can I find it ? I find an older thread here : http://cygwin.com/ml/cygwin-xfree/2006-10/msg00045.html with the same problem but without solution. any ideas ? Regards, -- 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/
Issue after installing cygwin
Hello, I have been using cygwin since long. Recently I was trying to help my friend install cygwin on his desktop. After a successful installation, the startxwin.bat was run to start the workspaces. However, after starting the workspaces, the green coloured Window Maker Preferences icon does not appear in the workspaces. The same setup was used to install cygwin on my machine and I could use the Window Maker Preferences to configure my shortcuts. But somehow this does not appear on my friends desktop. Any idea Any help in making this icon visible is highly appreciated... Regards, Mansoorali. -- 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: Issue after installing cygwin
Mansoorali Kudsi wrote: Hello, I have been using cygwin since long. Recently I was trying to help my friend install cygwin on his desktop. After a successful installation, the startxwin.bat was run to start the workspaces. However, after starting the workspaces, the green coloured Window Maker Preferences icon does not appear in the workspaces. The same setup was used to install cygwin on my machine and I could use the Window Maker Preferences to configure my shortcuts. But somehow this does not appear on my friends desktop. Can't remember exactly, but, some time ago (1 year), it happened to me to have problems with Window Maker in a new installation of Cygwin. It seems to me that I was unable to access the WMaker preferences, anyway I solved creating a link or two: try to start Window Maker by hand from a terminal, so to have a look at its output/trace and whether it misses some file/directory. Any idea Any help in making this icon visible is highly appreciated... Regards, Mansoorali. -- 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/ -- 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: Issue after installing cygwin
Mansoorali Kudsi wrote: Hello, I have been using cygwin since long. Recently I was trying to help my friend install cygwin on his desktop. After a successful installation, the startxwin.bat was run to start the workspaces. However, after starting the workspaces, the green coloured Window Maker Preferences icon does not appear in the workspaces. The same setup was used to install cygwin on my machine and I could use the Window Maker Preferences to configure my shortcuts. But somehow this does not appear on my friends desktop. Any idea Any help in making this icon visible is highly appreciated... Maybe I'm wrong but I found: $ ll /usr/X11R6/GNUstep/ total 1 drwxrwx---+ 3 abcdefg Users0 Feb 4 16:48 Applications/ lrwxrwxrwx 1 abcdefg mkgroup_l_d 14 Feb 4 17:41 Apps - ./Applications/ It seems to me that I needed to create that link named Apps to the Applications directory. Regards, Mansoorali. -- 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/ -- 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/
WG: Can't build cygwin X server : directory program/xrx is missing
Install the sources from the cvs STABLE tree. xrx is in the stable tree. Regards -Ursprüngliche Nachricht- Von: patrick ficheux [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. April 2008 10:30 An: cygwin-xfree@cygwin.com Betreff: Can't build cygwin X server : directory program/xrx is missing I'm trying to rebuild X server (XWin.exe) from the source tree xorg-x11 6.8.99.901-1 (last stable version) when I run 'make', I get those errors $ make World ... make[3]: Leaving directory `/usr/src/xc/programs/xrefresh' cleaning in programs/xrx... make: Entering an unknown directory make: *** xrx: No such file or directory. Stop. make: Leaving an unknown directory make[2]: *** [clean] Error 2 make[2]: Leaving directory `/usr/src/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/usr/src/xc' make: *** [World] Error 2 The directory /usr/src/xc/programs/xrx is missing The source package of xorg-x11-bin (which contains xrx.exe) doesn't contain this directory Where can I find it ? I find an older thread here : http://cygwin.com/ml/cygwin-xfree/2006-10/msg00045.html with the same problem but without solution. any ideas ? Regards, -- 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/
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-04-29 09:24:54 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (rename): Use volume serial numbers stored in path_conv rather than fetching them here for the same file test. Change comment to reflect this. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4130r2=1.4131 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.489r2=1.490
src/winsup/cygwin ChangeLog mount.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-04-29 20:48:09 Modified files: winsup/cygwin : ChangeLog mount.cc Log message: * mount.cc (mount_info::from_fstab): Skip native path prefix in module path. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4131r2=1.4132 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.cc.diff?cvsroot=srcr1=1.3r2=1.4
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
[EMAIL PROTECTED] wrote: Spiro Trikaliotis wrote on 26 April 2008 10:42: Anyway, this reminds me of another problem: Personally, I install Cygwin with DOS line endings (CR/LF). That's the reason why I have built CVS.EXE myself some moons ago ;), as the pre-built version did not like this setup. (IIRC, the outputs were garbled in many places. At the time when I tested it, it was a known issue on the info-cvs mailing list.) At least CVS checks out the text files in the native format of the platform - as I am using Cygwin with CR/LF, this is the CR/LF format. Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. Well, Cygwin's Subversion simply does not respect text mounts (compared to CVS) and that's hardly something for upstream. - Jörg -- 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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On Apr 28 19:44, Charles Wilson wrote: Charles Wilson wrote: Yeah, I'll code that up for 1.5-4. Should I stick with BUFSIZ == 1024, or when MMAP use something a little bigger, say 32k? Also, uploads to the server seem to be sane (e.g. read() from the server side). So it's just downloads to the client when HAVE_MMAP. The fix was pretty easy: #ifdef HAVE_MMAP #include sys/mman.h +# ifdef __CYGWIN__ + /* On cygwin, network transfers are limited to an absolute + maximum of 64k, or transfer fails with ENOBUFS. Conservative: */ +# define LARGE_TRANSFER_LIMIT 32768 +# endif #endif In theory that looks fine, I just don't like the comment. This is not Cygwin's fault in the first place and it's not Cygwin returning ENOBUFS when you use too big send calls in the first place. Also, Cygwin does not return ENOBUFS for writes 64K. The 1.5 versions lets you do what you want and you have to deal with Winsock's behaviour directly. The 1.7 version just sends a maximum of 64K regardless of the incoming buffer size. It doesn't refuse the write completely. Eventually we should do our own write buffer management in Cygwin so you won't have to care. Brian Ford is looking into it, afaik. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Jörg Schaible wrote on 29 April 2008 07:39: [EMAIL PROTECTED] wrote: Say, has your Outlook Quotefix gone screwy too? Spiro Trikaliotis wrote on 26 April 2008 10:42: Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. Well, Cygwin's Subversion simply does not respect text mounts (compared to CVS) and that's hardly something for upstream. Hmm, well it might or might not be, it depends what method it's using to determine the native mode. If it was simply fopen()ing a file in text mode and writing, it would of course respect textmode mounts automatically. Perhaps it manages it all manually by always writing in binary mode, and it inherently assumes that all filing systems operate in the same textmode, and some test it does misleads it? It also depends on the attitude of the upstream maintainers to accepting platform-specific patches. cheers, DaveK -- Can't think of a witty .sigline today -- 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: FW: ssmtp with multiple email accounts
Well, then mutt lets you choose *its* configuration file. Yeah, but then I have to know in advance which emails I am going to send before starting mutt, and I'm not that organised (it is pretty impractical anyway, due to replying to mails using different From addresses). Maybe my best bet is to run a script from mutt's send-hook to set up the ssmtp.conf correctly for the outgoing mail. Or maybe it is even possible to set the sendmail variable in the send-hook to something like /usr/sbin/ssmtp.exe -C~/.ssmtp/local-part.domain.conf. I was just kind of hoping someone had already done something, to save me the work :-) or that I'd just missed something in the way I am using mutt. -- 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: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Dave Korn wrote: Jörg Schaible wrote on 29 April 2008 07:39: [EMAIL PROTECTED] wrote: Say, has your Outlook Quotefix gone screwy too? Spiro Trikaliotis wrote on 26 April 2008 10:42: Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. Well, Cygwin's Subversion simply does not respect text mounts (compared to CVS) and that's hardly something for upstream. Hmm, well it might or might not be, it depends what method it's using to determine the native mode. If it was simply fopen()ing a file in text mode and writing, it would of course respect textmode mounts automatically. Perhaps it manages it all manually by always writing in binary mode, and it inherently assumes that all filing systems operate in the same textmode, and some test it does misleads it? It also depends on the attitude of the upstream maintainers to accepting platform-specific patches. Well, it might be very well that Subversion always uses binary mode for file I/O, it will even convert text files on its own if the svn:eol-style property is set (unless your file has no mixed EOLs). OTOH it cannot know that an environment uses two different native modes, that's quite a Cygwin speciality. So, it's some kind of catch-22 ;-) - Jörg -- 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: cpan has a problem Writing Makefile
2008/4/28 Chap Harrison: Reini Urban wrote: Well, then the error is fixed. You reported that the Makefile could not be written. Now it is written, and you can proceed installing it. Reading the README would have helped. http://search.cpan.org/src/HMBRAND/Text-CSV_XS-0.45/README Perhaps I should have said cpan has a problem installing Text::CSV_XS. There was no README to read. CPAN still craps out installing Text::CSV__XS, exactly as before. That's the error, and it's not fixed. If you encounter an error with cpan, first have a look in the package description and bug reports at http://search.cpan.org/dist/Text-CSV_XS/ The README also helps. Please report at the link [ View/Report Bugs (2) ] there. Since you can write the Makefile within the debugger and not via the shell there is some weird problem on your side. All cygwin smoke tests passed. http://cpantesters.perl.org/show/Text-CSV_XS.html#Text-CSV_XS-0.45 A suggestion would be to install CPAN::Reporter and report the failure automatically, since you are not able to follow README's and submit proper bugreports. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: FW: ssmtp with multiple email accounts
Gary, On Tue, Apr 29, 2008 at 11:55:46AM +0200, Gary wrote: I was just kind of hoping someone had already done something, to save me the work :-) or that I'd just missed something in the way I am using mutt. I use fetchmail to pull down mail from multiple accounts (via IMAP and POP) to mbox files, one ssmtp configuration to send all outgoing mail [1], and mutt to read and write them. Why do you need multiple ssmtp configurations? Why can't you just use ssmtp to relay to your ISP's SMTP server for all of your outgoing mail? You can do this even if you use mutt to access your email via IMAP and/or POP directly. Jason [1] More precisely, I use ssmtp to deliver to my local exim server which is configured to relay to my ISP's SMTP server. -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: FW: ssmtp with multiple email accounts
Why do you need multiple ssmtp configurations? Why can't you just use ssmtp to relay to your ISP's SMTP server for all of your outgoing mail? I don't have access to a mailhub which allows what I need given ssmtp's limitation of one authenticating user. Taking one of the two that I use, gmail for my domain, as an example - It is required to authenticate using the name of the user sending the mail, which means that ssmtp.conf has to include that information (SmtpAuth=, I think, but don't have access to it ATM). If several users, i.e. me using several addreses on my domain for different reasons, want to send mail then ssmtp has to somehow know which user it has to authenticate with. It gets worse in that I have another account completely separate from gmail and my domain that I also want to send email from - they won't allow me to send email using any different address than is with them via their servers any more than gmail will allow me to send email for the separate email address (I could make it an alias in gmail, but would rather not). Maybe exim can be configured to do that translation, I don't know, but a) I prefer to have as few daemons/services running as I can, and b) secure configuration looks like a PITA. Other than that, I'm open to suggestions. -- 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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
antony baxter wrote: Better, in the sense that I can now retrieve the file; however ftpd.exe's memory usage (monitored via Task Manager) now grows continously during the transfer until eventually the server machine grinds to a halt, paging furiously. Once the transfer does finally finish ftpd.exe's memory usage drops back to normal (2,400K). Hmm. A little more research shows winsock's internal behavior -- transfers, waitiong for ack, allocating internal buffers -- is very sensitive to the size of so_sndbuf (winsock default 8192) and the packet size (ethernet default 1560). See if one of these options gives better performance: http://cygwin.cwilson.fastmail.fm/ITP/ftpd-1k.exe.bz2 http://cygwin.cwilson.fastmail.fm/ITP/ftpd-4k.exe.bz2 http://cygwin.cwilson.fastmail.fm/ITP/ftpd-8k.exe.bz2 http://cygwin.cwilson.fastmail.fm/ITP/ftpd-32k.exe.bz2 (same as prev) Also, what is the value of HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize -- Chuck -- 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/
openssh, bash.exe, windows 2003, bash stay open
Hi, I'm using Openssh under Cygwin on many Windows 2003 servers. The problem: my users kill the ssh connection (putty and ssh) instead of using the exit command so the bash.exe attached with session stay open and eventually this cause a problem ( sshd: PID 1944: error: session_pty_req: session 0 alloc failed.) It's seems strange to me that the bash.exe stay open. Do you have any idea how to solve this issue? The really old port of openssh for windows http://sshwindows.sourceforge.net/; don't have this problem. Thanks, François
File path to URI
Hello, Has anyone seen a command line tool for converting path (e.g. /cygdrive/h/privat/news_alert.conf) to file URI (file:///cygdrive/h/privat/news_alert.conf) Yes, tweaking with string concatenation or calling some java code would be a way, though I would prefer some proper command within the cygwin - bash domain. Thanks in advance for any suggestion. Cheers, b. _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline -- 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: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello, * On Tue, Apr 29, 2008 at 12:58:53PM +0200 Jörg Schaible wrote: Well, it might be very well that Subversion always uses binary mode for file I/O, Indeed, it seems so. This topic came up before (see the thread started at http://svn.haxx.se/dev/archive-2005-02/0993.shtml), and the way Subversion works has not been changed yet. In http://svn.haxx.se/dev/archive-2005-02/1034.shtml, it is described as follows: Look at the function svn_subst_eol_style_from_value() in the file subversion/libsvn_subr/subst.c. That function determines what the various svn:eol-style settings mean and you will see that native leads to APR_EOL_STR, i.e. Subversion gets the value from APR. There is even a work-around available to change this behaviour: You could change svn_subst_eol_style_from_value() and rebuild Subversion, or you could change APR_EOL_STR and rebuild all of APR, APR-UTIL and Subversion, it depends what behaviour you want. Anyway, I already asked for the Antivirus-Workaround upstream, I will propose some change here, too. Unfortunately, as Subversion is currently at 1.5 RC4, I doubt they will include such changes for 1.5. Anyway, I will try. Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- 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: cygwin emacs Vista: linked dll data write copy failed
I ran into the same problem. It looks like the Symantec rtvscan-32 on vista is causing the problem. I was hoping to see some sort of solution in the URL below short of not using Symantec, but the URL is dead. Is it available elsewhere? Rick Raunch wrote: I used the latest setup program and was getting an error when opening xterms sporatically; if I got the error, the X-window wouldn't be created. If I tried several times usually one would take. Shelling or running perldb in emacs would consistently product this problem. I got a message that said, linked dll data write copy failed. I found this on the web: http://pseudocode.cc/?m=200705 My problem was essentially the same as the one posted at the above URL. The fix described there solved my problems as well. It looks like this problem has been out there for a number of months and I was unable to find a reference to this work-around in this list's archive. So I thought that I'd post it here. -- 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/ -- View this message in context: http://www.nabble.com/cygwin-emacs-Vista%3A-linked-dll-data-write-copy-failed-tp15172849p16967658.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: cygwin emacs Vista: linked dll data write copy failed
The URL below seems dead. Is the answer available elsewhere Rick Raunch wrote: I used the latest setup program and was getting an error when opening xterms sporatically; if I got the error, the X-window wouldn't be created. If I tried several times usually one would take. Shelling or running perldb in emacs would consistently product this problem. I got a message that said, linked dll data write copy failed. I found this on the web: http://pseudocode.cc/?m=200705 My problem was essentially the same as the one posted at the above URL. The fix described there solved my problems as well. It looks like this problem has been out there for a number of months and I was unable to find a reference to this work-around in this list's archive. So I thought that I'd post it here. -- 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/ -- View this message in context: http://www.nabble.com/cygwin-emacs-Vista%3A-linked-dll-data-write-copy-failed-tp15172849p16967686.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 cygserver and sysv message queues: msgsnd() blocks forever.
I've been debugging a problem with msgsnd() hanging. If there are no free
msghdrs available, msgsnd() blocks with msleep(). Unfortunately, the only way
it can unblock is if that specific queue frees a msghdr. If the queue in
question is empty, this never occurs. I was able to isolate this behavior in
set of examples, which I've attached. The program doqueue.c establishes a queue
and upon each ENTER, calls msgsnd() followed by msgrcv(). Start this one first
and verify that messages cycle normally.
In another window, run overflow.c. This establishes a different queue, and
calls msgsnd() until the queue is full, then exits. In the default
configuration, that will happen at 40 messages. Go back to the first window and
press ENTER. the call to msgsnd() will block. Then, either run drainq to remove
messages from overflow's queue, or use ipcrm -q 4660 to delete the queue
entirely. Doqueue will remain blocked.
It's possible to work around this by using the flag IPC_NOWAIT in msgsnd, and
polling until the message is sent, but my feeling is that the library call
should not hang like this.
Here is the code in question:
From sysv_msg.cc, function msgsnd():
=
if (free_msghdrs == NULL) {
DPRINTF((no more msghdrs\n));
need_more_resources = 1;
}
if (need_more_resources) {
int we_own_it;
if ((msgflg IPC_NOWAIT) != 0) {
DPRINTF((need more resources but caller
doesn't want to wait\n));
error = EAGAIN;
goto done2;
}
if ((msqptr-msg_perm.mode MSG_LOCKED) != 0) {
DPRINTF((we don't own the msqid_ds\n));
we_own_it = 0;
} else {
/* Force later arrivals to wait for our
request */
DPRINTF((we own the msqid_ds\n));
msqptr-msg_perm.mode |= MSG_LOCKED;
we_own_it = 1;
}
DPRINTF((goodnight\n));
error = msleep(msqptr, msq_mtx, (PZERO - 4) | PCATCH,
msgwait, 0);
DPRINTF((good morning, error=%d\n, error));
==
The call to msleep() above passes msqptr (the queue handle) as the Ident
pointer. Each of the calls to wakeup() in sysv_msg.cc also passes msgptr as the
ident. This means that if the msghdr resource is free'd by a queue other than
the one blocked, it won't wake up msgsnd(). Since doqueue's queue is empty,
there is no way to wake up msgsnd().
Here is a snippet from /var/log/messages:
Apr 29 13:38:16 motonao cygserver: call to msgsnd(131072, 0x22CCD8, 1, 0)
Apr 29 13:38:16 motonao cygserver: msgsz=1, msgssz=8, segs_needed=1
Apr 29 13:38:16 motonao cygserver: no more msghdrs
Apr 29 13:38:16 motonao cygserver: we own the msqid_ds
Apr 29 13:38:16 motonao cygserver: goodnight
Apr 29 13:38:24 motonao cygserver: msgget(0x1234, 00)
Apr 29 13:38:24 motonao cygserver: found public key
Apr 29 13:38:24 motonao cygserver: call to msgrcv(196609, 0x22CCD8, 1, 0, 0)
Apr 29 13:38:24 motonao cygserver: found a message, msgsz=1, msg_ts=1
The first line is doqueue's last call to msgsnd(). It finds there are no free
msghdrs and logs the message no more msghdrs, then logs goodnight and calls
msleep(). The call to msgrcv is drainq removing a message from the overflow
queue. This is the point where we would like to see the good morning message
from msgsnd(), but we don't.
I haven't been able to spot a way to fix this behavior without significantly
changing the block/release mechanism. Has anyone seen this before? Have I
missed something? Is this simply a known limitation, with IPC_NOWAIT the only
way to deal with it?
~
David Williams
Solekai Systems
#include stdio.h
#include stdlib.h
#include unistd.h
#include ctype.h
#include sys/types.h
#include sys/ipc.h
#include sys/msg.h
#include errno.h
#define MSGQ_KEY 0x1234
#define PERM 0660
struct mymsg {
long mtype;
char mtext[1];
};
int
main()
{
int msg_id; /* message Queue id. */
struct mymsg msg; /* message to send. */
int nmsg; /* number of msg send. */
int status; /* status returned by msgsnd(). */
/*
* Create Message Queue
*/
if ( (msg_id = msgget (MSGQ_KEY, PERM | IPC_CREAT)) == -1 ) {
perror (msgget: );
exit (EXIT_FAILURE);
}
/*
* now write message one by one until Queue is full
*/
msg.mtype = 1;
msg.mtext[0] = 'A';
nmsg = 0;
do {
printf (Receiving #%d\n, nmsg);
status = msgrcv (msg_id, msg, sizeof(msg.mtext), 0, 0);
printf (Received msg #%d\n, nmsg);
nmsg++;
}
while ( tolower(getchar()) != 'q' );
exit (EXIT_SUCCESS);
}
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/ipc.h
#include sys/msg.h
#include errno.h
#define MSGQ_KEY 0x1234
#define PERM 0660
struct mymsg {
long mtype;
char mtext[1];
};
int
main()
{
int msg_id; /* message Queue id. */
struct mymsg msg; /* message to send. */
int nmsg; /* number of msg send. */
int status; /*
Problem with cygserver and sysv message queues: msgsnd() blocks forever.
Sorry, the first try was badly formatted. I didn't realize
until I checked the archive site.
I've been debugging a problem with msgsnd() hanging. If
there are no free msghdrs available, msgsnd() blocks with
msleep(). Unfortunately, the only way it can unblock is
if that specific queue frees a msghdr. If the queue in
question is empty, this never occurs. I was able to isolate
this behavior in set of examples, which I've attached. The
program doqueue.c establishes a queue and upon each ENTER,
calls msgsnd() followed by msgrcv(). Start this one first
and verify that messages cycle normally.
In another window, run overflow.c. This establishes a
different queue, and calls msgsnd() until the queue is full,
then exits. In the default configuration, that will happen at
40 messages. Go back to the first window and press ENTER. the
call to msgsnd() will block. Then, either run drainq to remove
messages from overflow's queue, or use ipcrm -q 4660 to delete
the queue entirely. Doqueue will remain blocked.
It's possible to work around this by using the flag IPC_NOWAIT
in msgsnd, and polling until the message is sent, but my feeling
is that the library call should not hang like this.
Here is the code in question:
From sysv_msg.cc, function msgsnd():
=
if (free_msghdrs == NULL) {
DPRINTF((no more msghdrs\n));
need_more_resources = 1;
}
if (need_more_resources) {
int we_own_it;
if ((msgflg IPC_NOWAIT) != 0) {
DPRINTF((need more resources but caller
doesn't want to wait\n));
error = EAGAIN;
goto done2;
}
if ((msqptr-msg_perm.mode MSG_LOCKED) != 0) {
DPRINTF((we don't own the msqid_ds\n));
we_own_it = 0;
} else {
/* Force later arrivals to wait for our
request */
DPRINTF((we own the msqid_ds\n));
msqptr-msg_perm.mode |= MSG_LOCKED;
we_own_it = 1;
}
DPRINTF((goodnight\n));
error = msleep(msqptr, msq_mtx, (PZERO - 4) | PCATCH,
msgwait, 0);
DPRINTF((good morning, error=%d\n, error));
==
The call to msleep() above passes msqptr (the queue handle)
as the Ident pointer. Each of the calls to wakeup() in
sysv_msg.cc also passes msgptr as the ident. This means that
if the msghdr resource is free'd by a queue other than the one
blocked, it won't wake up msgsnd(). Since doqueue's queue is
empty, there is no way to wake up msgsnd().
Here is a snippet from /var/log/messages:
Apr 29 13:38:16 motonao cygserver: call to msgsnd(131072, 0x22CCD8, 1, 0)
Apr 29 13:38:16 motonao cygserver: msgsz=1, msgssz=8, segs_needed=1
Apr 29 13:38:16 motonao cygserver: no more msghdrs
Apr 29 13:38:16 motonao cygserver: we own the msqid_ds
Apr 29 13:38:16 motonao cygserver: goodnight
Apr 29 13:38:24 motonao cygserver: msgget(0x1234, 00)
Apr 29 13:38:24 motonao cygserver: found public key
Apr 29 13:38:24 motonao cygserver: call to msgrcv(196609, 0x22CCD8, 1, 0, 0)
Apr 29 13:38:24 motonao cygserver: found a message, msgsz=1, msg_ts=1
The first line is doqueue's last call to msgsnd(). It finds
there are no free msghdrs and logs the message no more msghdrs,
then logs goodnight and calls msleep(). The call to msgrcv is
drainq removing a message from the overflow queue. This is the
point where we would like to see the good morning message from
msgsnd(), but we don't.
I haven't been able to spot a way to fix this behavior without
significantly changing the block/release mechanism. Has anyone
seen this before? Have I missed something? Is this simply a known
limitation, with IPC_NOWAIT the only way to deal with it?
~
David Williams
Solekai Systems
#include stdio.h
#include stdlib.h
#include unistd.h
#include ctype.h
#include sys/types.h
#include sys/ipc.h
#include sys/msg.h
#include errno.h
#define MSGQ_KEY 0x1234
#define PERM 0660
struct mymsg {
long mtype;
char mtext[1];
};
int
main()
{
int msg_id; /* message Queue id. */
struct mymsg msg; /* message to send. */
int nmsg; /* number of msg send. */
int status; /* status returned by msgsnd(). */
/*
* Create Message Queue
*/
if ( (msg_id = msgget (MSGQ_KEY, PERM | IPC_CREAT)) == -1 ) {
perror (msgget: );
exit (EXIT_FAILURE);
}
/*
* now write message one by one until Queue is full
*/
msg.mtype = 1;
msg.mtext[0] = 'A';
nmsg = 0;
do {
printf (Receiving #%d\n, nmsg);
status = msgrcv (msg_id, msg, sizeof(msg.mtext), 0, 0);
printf (Received msg #%d\n, nmsg);
nmsg++;
}
while ( tolower(getchar()) != 'q' );
exit (EXIT_SUCCESS);
}
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/ipc.h
#include sys/msg.h
#include errno.h
#define MSGQ_KEY 0x1234
#define PERM 0660
struct mymsg {
long mtype;
char mtext[1];
};
int
main()
{
int msg_id; /* message Queue id. */
struct mymsg msg; /* message to
[ANNOUNCEMENT] Updated: {xerces-c/libxerces-c28/libxerces-c-devel/xerces-c-doc/xerces-c-test}-2.8.0-3
I've updated the xerces-c version to 2.8.0-3. (2.8.0-2 appeared briefly on the mirrors but was withdrawn) xerces-c is a validating XML parser written in a portable subset of C++ (it is also known as Xerces-C++). xerces-c makes it easy to give your application the ability to read and write XML data. A shared library is provided for parsing, generating, manipulating, and validating XML documents. Changes since 2.8.0-1 == * fixed packaging bug with postinstall scripts (reported by Dr. Volker Zell) * fixed packaging bug induced by upstream 'packageBinaries.pl' script, which shamefully excluded the Cygwin-specific public header files from the staging area. Because 2.8.0-1 was released only a short while ago, and was a significant change relative to the previous official cygwin xerces-c package (2.5.0-1), please review also these changes: http://cygwin.com/ml/cygwin-announce/2008-04/msg00041.html -- Chuck To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: cpan has a problem Writing Makefile
Reini Urban wrote: A suggestion would be to install CPAN::Reporter and report the failure automatically, since you are not able to follow README's and submit proper bugreports. -- Reini Urban Dude, I don't know what your problem is. I just came in here looking for help. Glad to read anything and follow guidelines. Have no prior knowledge of how to deal with CPAN problems, because CPAN's always worked for me in Darwin. I'm just trying to install Cygwin so I have access to good tools inside Windows. Thanks for pointers. Insults? No thanks. -- View this message in context: http://www.nabble.com/cpan-has-a-problem-Writing-Makefile-tp16909407p16974255.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles Wilson wrote: http://cygwin.cwilson.fastmail.fm/ITP/ftpd-1k.exe.bz2 http://cygwin.cwilson.fastmail.fm/ITP/ftpd-4k.exe.bz2 http://cygwin.cwilson.fastmail.fm/ITP/ftpd-8k.exe.bz2 http://cygwin.cwilson.fastmail.fm/ITP/ftpd-32k.exe.bz2 (same as prev) For ex, with the 32k buffers, here's what I see in the resource monitor (this is on Vista, cygwin-1.7) commit (KB)Working Set (KB)Shareable (KB) Private (KB) 3948 5,832 3,7162,116 when the client begins to 'get' the very large file, I can watch the Private allocations jump in 4k increments. Meanwhile the Working Set and Shareable both jump in 1300kB (or so) increments. This continues until a maximum of about: commit (KB)Working Set (KB)Shareable (KB) Private (KB) 4,488 240,000 238,0002,600 is reached. Once the transfer is complete, the numbers drop back down to the first set, above. However, for smaller sizes (4k, 1k) I get sane behavior -- see below. Another thing I noticed, was transfer speed: topology one: server=Vista, cygwin-1.7, wireless 802.11g client=XPsp2, cygwin-1.5, wireless 802.11g (both using the same access point, thus sharing the same nominal 54Mbps link) 64k buffers: 2 Mbps 32k buffers: 1 Mbps 8k buffers: 9 Mbps 4k buffers: 9-10 Mbps (sane!) 1k buffers; 8-9 Mbps (sane!) This poor behavior with 32k and 64k buffers could be a function of my AP not handling bi-di wireless transfers well, or the longer bursts forcing it to use the available bandwidth inefficiently. Trying again: Topology two: server=Vista, cygwin-1.7, wireless 802.11g client=linux, 100BaseT wired 64k buffers: 17-20 Mbps 32k buffers: 15-17 Mbps 8k buffers: 13-14 Mbps 4k buffers: 14-15 Mbps (sane!) 1k buffers; 13-14 Mbps (sane!) So, while you get better performance (in unshared topologies) with the larger buffer sizes, the 4k and 1k buffers exhibit sane behavior with respect to the Working Set and Shareable memory allocations: (1) they stay around 5MB to 6MB rather than ballooning up to 240MB. (2) I actually see the numbers go down occasionally, instead of always increasing until the transfer is complete. That's good enough for me to forego the improvement in transfer speed (which is anywhere from 13%--42% if you compare best/worst and worst/best between 64k and 4k on non-shared topologies) -- and avoid the awful behavior on shared topologies. Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). -- Chuck -- 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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles, Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). Squawk! Unfortunately, with XP SP2, Cygwin 1.5 as the server machine, I get pretty much the same symptoms with each of the above ftpds serving up a 350mb file: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Sorry! Ant. -- 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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles, Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). Charles, Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). Squawk! Unfortunately, with XP SP2, Cygwin 1.5 as the server machine, I get pretty much the same symptoms with each of the above ftpds serving up a 350mb file: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Quick addendum: I copied over in.ftpd.exe from another Cygwin installation running inetutils 1.3.2 and symlinked it to ftpd on my server; using that to serve the same file, memory usage sticks at 3500kb, cpu usage never rises about 5%, and the file was delivered in 194 seconds. Ant. -- 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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
antony baxter wrote: Unfortunately, with XP SP2, Cygwin 1.5 as the server machine, I get pretty much the same symptoms with each of the above ftpds serving up a 350mb file: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Quick addendum: I copied over in.ftpd.exe from another Cygwin installation running inetutils 1.3.2 and symlinked it to ftpd on my server; using that to serve the same file, memory usage sticks at 3500kb, cpu usage never rises about 5%, and the file was delivered in 194 seconds. Well, one of the differences between ftpd-1.3.2 and ftpd-1.5 is that the newer version uses mmap on the (local) file. ftpd.c is the /only/ source file in inetutils that uses mmap. So, I recompiled with HAVE_MMAP turned off (but still using 4k chunks). Give this a try: http://cygwin.cwilson.fastmail.fm/ITP/ftpd-no-mmap-4k.exe.bz2 I get behavior here which is very similar to what I reported for the 4k-WITH-mmap version: (1) sane memory profile (2) topology one, 9-10 Mbps 2-3% cpu (3) topology two, 14-15 Mbps, 4-6% cpu [*] I'm not sure what benefit mmap has in this case -- unless you can exploit some zero-copy kernel code for transferring data from disk to ethernet device. But I don't think Windows has anything like that. I certainly don't *see* any benefit, in my limited testing on this set of hardware. If this *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. -- Chuck [*] However, with the mmap'ed, 4k buffer version, I also saw only 4-6% CPU utilization on Vista, cygwin-1.7. So, YMMV. -- 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/
