Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-66
Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen : Hi folks, I just uploaded a new Cygwin 1.7 test release, 1.7.0-66. If this doesn't introduce any new regressions, this will (probably) be the last test release. Greetings, after having played with Cygwin 1.5 on XP SP3 for a long while, for so long that I forgot what I initially changed, I've now tried a fresh install of Cygwin on 1.7 (still with 1.7.0-65) on a fresh Windows 7 Professional 32-bit install. The one thing that got me wondering is that /etc/passwd uses /home/$LOGNAME (/home/hans for instance), rather than $USERPROFILE (/cygdrive/C/Users/hans), for the home directory. Is it intentional that Cygwin creates a second home for users? Thanks. Best regards -- Matthias Andree -- 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: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-66
Am 26.11.2009, 16:58 Uhr, schrieb Corinna Vinschen : This circumvents a few installation problems and decouples the Cygwin homedir by default from the Windows profile directory, which especially starting with Vista results in performance problems due to the new Explorer behaviour concerning "shared" files. If you want to use the Windows profile dir as home dir, set $HOME or tweak your /etc/passwd entry accordingly. Hi Corinna, Thanks for showing this to me again, I'd probably let it pass by since Windows 7 wasn't on my screen back then. Fair enough. A couple of hardlinks should then sort out the few cases where I can share a configuration between $HOME and $USERPROFILE when running both a Cygwin and a native Win32 version of the same application. Good speed with the official 1.7! Best regards -- Matthias Andree -- 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: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-68
Am 04.12.2009, 18:34 Uhr, schrieb Hugh Myers : Then I don't understand what "disallowed to" means. Would "disallowed duplicating file descriptors" sound more familiar to a native speaker? (Just wondering, English is also only 2nd language for me.) -- Matthias Andree -- 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: Possible BSOD from getcwd on WinXP SP3
Am 13.01.2010 16:18, schrieb Henson, George A CTR USA MEDCOM JMLFDC: > A very deep directory tree called conftest3 > (conftest3/conftest3/conftest3/...) > The source for conftest (conftest.c - attached) > Compiled binary contest.exe > > In Cygwin attempting to cd to the bottom of the conftest3 directory tree > will yield a BSOD. Running conftest.exe will yield a BSOD. A little > experimentation with conftest.c shows the error happens during the > creation of the directory tree. The Windows native tools are unable to > correctly manage the conftest3 tree (I cannot remove it or descend to > the bottom) > > The only information I have been able to get out of the Windows crash > dumps is the fault happens somewhere in the ntfs.sys driver. Might this be simple filesystem corruption? If so, chkdsk might be your friend - give it a spin. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can't set variables in a while loop that is passed to the rest of the script.
Am 15.01.2010, 00:40 Uhr, schrieb Jeremy Bopp :
On 1/14/2010 5:23 PM, Damo, David wrote:
Hi,
I have fixed the problem. It seems in cygwin it spawns a subshell even
under bash. I used a for loop instead and everything worked nicely.
for line in `sed 's/\$/^/g' $propfile`
do
nvpair=$(echo $line | awk -F"=" '{print $1,$2}')
set -- $nvpair
if [ ! "$1" = "" ]; then
eval "$1"=\"$2\"
fi
done
Interesting. Your workaround should work fine as long as the propfile
is not too large, I think. However, wouldn't it be easier to source a
properly massaged version of propfile instead?
The observed behaviour ("sed ... | while read foo" not setting variables
properly) is expected and documented, because the commands in a pipe will
be launched in a subshell (per POSIX), where "in the current shell" is an
exception you cannot rely on - as observed.
See IEEE Std 1003.1-2008, Shell & Utilities, Shell Command Language, 2.12
Shell Execution Environment (near the end of the section).
I'd consider using the for line a fix, rather than a workaround.
I'd also recommend a good portion of caution when sourcing generated
files. This all too easily becomes a major security concern unless
combined with thorough error checking. "set -e" is a bare necessity, and
security isn't halfway complete there...
--
Matthias Andree
--
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: [ANNOUNCEMENT] Updated: qrupdate-1.1.0-1
Am 24.01.2010, 08:56 Uhr, schrieb Marco Atzeri : The version 1.1.0-1 of qrupdate(source), libqrupdate-devel, libqrupdate0 have been uploaded. It is one of the package needed to fully compile Octave-3.2.x and following DESCRIPTION QRUPDATE is a library for fast updating of QR and Cholenski Please check the name - Choleski is spelled without n in my book... (feel free to forward the report upstream if the misspelling is "inherited".) -- Matthias Andree -- 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: cygport fails when the working directory pathname contains spaces
Am 27.01.2010, 09:13 Uhr, schrieb Yaakov (Cygwin/X) : On 26/01/2010 23:38, Steven Monai wrote: Imagine if a program like 'cp' failed because the current working directory has a pathname that contains spaces. You'd probably agree with me that 'cp' had a rather serious flaw, wouldn't you? cygport is not 'cp'. cygport is a shell script, as are configure scripts, the autoconf-generated kind being the most common build system out there. Shell scripts usually use spaces for IFS. Hence distinguishing between a space in a file name/path and whitespace between arguments is fraught with difficulties. I stand by my original report. This is a bug. Not a serious show-stopper by any stretch, but a bug, nonetheless. > When I find the time and motivation, I may try my hand at fixing it myself. I'll report back with patches if I do. As the author of cygport, I'll advise you that your time will be much better spent getting used to not using spaces in file and directory names rather than pretending to "fix" a case that will never be guaranteed to work. This isn't acceptable as a generic statement. If you're unwilling to fix the cygport parts of the bug, that's fine, but claiming that fixing it were generally not worthwhile amounts to blessing insecure programming practices. If shell scripts, including cygport, cannot be bothered to quote variables properly, worse things can happen than just blanks, think for instance glob special characters or semicolons. This routinely raises SECURITY ISSUES unless you're using 100% trusted data, IOW, scripts that fail on blanks in path names, will do worse things under attack. And now consider how many people are actually using Cygwin on systems where running with Administrator privileges is commonplace (XP...) And I've made other packages work in directories that contain blanks, for instance bogofilter including test suite. It was some work to revisit all of the scripts, but not a major undertaking. Of course fixing cygport won't assure its user that the package itself is safe in paths with blanks, but at least then you can say that you've done your part and the fix is SOEP (someone else's problem). That other parts might fail is NOT AN excuse to not do your own job in a way that breaks other people's expectations. I'd seriously ask you to reconsider. -- Matthias Andree -- 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: cygport fails when the working directory pathname contains spaces
Am 27.01.2010, 03:09 Uhr, schrieb Steven Monai: Hi folks, Consider this command line transcript: -- $ uname -a CYGWIN_NT-5.1 hostname 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin $ cygcheck -c cygport Cygwin Package Information Package VersionStatus cygport 0.9.80-1 OK $ pwd /home/steve/My Documents/bglibs $ ls bglibs-1.106-1.cygport $ cygport bglibs-1.106-1.cygport download /usr/bin/cygport: line 444: [: /home/steve/My: binary operator expected /usr/bin/cygport: line 450: /home/steve/My: No such file or directory -- Workaround: Move the working dir to a path not containing spaces. Or even simpler, cd to the DOS variant of the filename, try for instance: cd /home/steve/MYDOCU~1/bglibs (you need to check what the actual DOS path equivalent is on your system) This has worked quite well for me so far (and I changed my $HOME to not contain spaces, but use the DOS name, too). -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'git commit' problem
Am 27.01.2010, 07:11 Uhr, schrieb Sisyphus: Hi, This might be a general 'git' issue rather than something specific to Cygwin. (The only git I have used is Cygwin's git - version 1.5.4.) Yes it is a generic git issue. When I try to 'git commit' my amendments I often get hit with "* trailing whitespace (line xxx)" errors. Configure your editor to not leave whitespace at the end of lines (sometimes the features are named flowed mode or soft line breaks or similarly, not always obvious). Firstly, I'm wondering what's wrong with having whitespace at the end of a line ? Why should it prevent changes from being committed ? Non-printable characters that generate bogus diffs and hence make merging more difficult than necessary. Secondly, what's the best way to deal with this ? Can this check be easily disabled ? Yes, check man git-config. Please ask further questions on this topic on the git@ list. -- Matthias Andree -- 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: cron & Windows 7
Am 11.02.2010 14:41, schrieb Corinna Vinschen: > On Feb 11 08:25, Pierre A. Humblet wrote: >> - Original Message - >> From: "Shaddy Baddah" >> To: "Pierre A. Humblet" >> Cc: cygwin >> Sent: Wednesday, February 10, 2010 23:36 >> >> >> | Hi, >> | >> | On 11/02/2010 3:28 AM, Pierre A. Humblet wrote: >> | > I got reports that cron is having problems with Cygwin 1.7.1 on >> | > Windows 7 - 32 bits. >> | > They occur only with seteuid method 1, not with method 2 nor method 3. >> | >> | Based purely on the above (and not the rest of the report... sorry) I >> | suspect it might be due to a problem that has just been fixed in CVS >> | (http://cygwin.com/ml/cygwin-developers/2010-02/msg00037.html). If you >> | have time to kill before someone of authority intervenes, you may want >> | to try a snapshot (http://cygwin.com/snapshots/) and see if it helps. >> | >> >> Thanks Shaddy, I will point this to the user. >> However according to the mails on the developers' list I don't see why the >> changes would apply to Method 1. >> >> Pierre > > No, that's not related. But we had a few reports on the list already > concerning sshd and it seemed to be a problem with using a non-Domain > cyg_server user running sshd, which lead to a crippled token: > http://cygwin.com/ml/cygwin/2010-01/msg00334.html > This is not related to W7, but should be a problem starting with > Windows Server 2003. > > Pierre, you know a lot about this authentication stuff in Cygwin, you > applied a couple of patches yourself, and you have a copyright > assignment in place. If you think there's another problem lurking, > please help with debugging and patches. Hi everyone, let's not play Chinese Whispers. :-) I am the one who reported this issue to Pierre and who provided the logs. Windows 7 Professional 32-bit (German), build 7600, this computer is not a domain client, but standalone. Cygwin 1.7.1 release, cron logging to syslog-ng. Running cron as dedicated user fails for me - see the logs Pierre referred to. Configuring cyglsa as setuid method and running cron as "SYSTEM" works for me. Is trying the CVS or a snapshot (which one?) worthwhile? Anything besides cygwin1.dll to be replaced for a test? Best -- Matthias Andree -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Am 22.02.2010 17:25, schrieb Thomas Baker: > On Mon, Feb 22, 2010 at 11:41 PM, Gary wrote: >> What does the fetchmail log say? "fetchmail: MDA open failed"? > > The fetchmail simply reports that each message is "flushed". The log > entries in this regard are identical on both machines. The log makes > no reference in either case to MDA, even though on the netbook the > MDA is correctly invoked. The fetchmail man page does not say whether > MDA execution is logged, or whether there are more verbose forms of > logging that might catch this. It simply says the message was "flushed". For debugging, see <http://www.fetchmail.info/fetchmail-FAQ.html#G3> The information you provided so far suggests that fetchmail has delivered the message because procmail terminated successfully, or because (a) procmail stated there was a permanent error and (b) you're either running an old fetchmail version or you overrode the softbounce option. -- Matthias Andree -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Am 22.02.2010, 19:39 Uhr, schrieb Gary : On Mon, Feb 22, 2010 at 06:53:46PM +0100, Matthias Andree wrote: Am 22.02.2010 17:25, schrieb Thomas Baker: and (b) you're either running an old fetchmail version No, the version numbers Tom provided are current (or thereabouts). 6.3.9 may be the "current" Cygwin package, but the current upstream version is 6.3.14. -- Matthias Andree -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Am 25.02.2010 00:04, schrieb Thomas Baker:
>>> Are you configured for case sensitive filenames? What does the
>>> following indicate?
>>>
>>>$ regtool get '\HKLM\SYSTEM\CurrentControlSet\Control\Session
>>> Manager\kernel\obcaseinsensitive'
>>
>> I am on the road today with the netbook, and on the netbook the command
>> above yields a response of "1".
>
> On the desktop, I also get a response of "1".
>
>> I see that the command
>>$ cd /home
>>$ ls -n /home/tbaker TBaker
>> does _not_ work on the netbook, though I guess this will not be an issue
>> if the /etc/passwd on the netbook already uses "tbaker"?
>
> But on the desktop, I was able to make a link under /home:
>
> dr-xr-xr-x+ 1 tbaker None 0 2010-02-24 17:53 Administrator
> lrwxrwxrwx 1 tbaker None 12 2010-02-23 18:07 TBaker -> /home/tbaker
> dr-xr-xr-x+ 1 tbaker None 0 2010-02-24 17:53 tbaker
>
> That seems inconsistent, but I guess the changed /etc/passwd entry
> on the desktop has solved the problem, so I will not worry about this.
So to summarize, in spite of the obcaseinsensitive = 1 you have a case sensitive
?:/cygwin/home path. The passwd entry was pointing to an almost empty home
directory, and procmail consequently wasn't finding its procmailrc file.
For the fetchmail upstream (that's me), I take it that fetchmail behaved as
documented in that it launched procmail and injected the messages, procmail
delivered according to its built-in defaults or /etc/procmailrc, and fetchmail
removed the messages after successful delivery through procmail. (technically
successfully, i. e. messages are on disk somewhere -- that's all you get with
procmail).
Now, to set the records straight, fetchmail 6.3 does not and cannot do any kind
of delivery. It will use SMTP (via TCP), LMTP (via TCP or Unix socket), or an
MDA (via anonymous pipe) to inject messages.
For procmail, it is notorious and infamous for its awkward error handling (or
non-handling, I should say, it ignores most errors and happily continues with
the next rule). It's basically unusable because you never know where your mail
ends up unless all of these are fulfilled:
* you keep a LOGFILE so you manually look up where you mail ended up
* you add a rule like this after each and every other procmail recipe:
:0e
{
EXITCODE=75
HOST
}
* you use use proper options (such as w on filtering recipes) so that procmail
actually checks for errors
* you add an explicit rule to deliver to your default mailbox, for instance:
:0:
$DEFAULT
:0e
{
EXITCODE=75
HOST
}
This would be the minimum error-handling .procmailrc.
The :0e stuff was discussed on the procmail list (AFAIR) ages ago and does the
following:
- if the previous rule failed, change the exit code 75 (which is EX_TEMPFAIL in
/usr/include/sysexits.h)
- stop processing (that's what the HOST line does: it blanks the hostname, and
due to the mismatch, processing aborts).
Jason, would you include this EXITCODE/HOST stuff and other hints into your
Cygwin README file? I don't think the upstream version will ever change again,
procmail is apparently dead for nearly a decade. For debugging, I'd also suggest
to mention LOGABSTRACT=all and LOGFILE along with VERBOSE=yes.
LOGFILE=/dev/stderr may prove useful in command line testing.
I'd suggest to drop procmail in the long run and provide Sam Varshavchik's
maildrop instead. It is easier to configure and more robust, and it's actually
maintained.
--
Matthias Andree
--
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 in calling _stat() on Cygwin 1.7
Am 27.02.2010, 12:57 Uhr, schrieb Dave Lee : Is it a problem with _stat(), or did I make a mistake in the 2nd argument in calling _stat()? If it (meddling with internal affairs, such as using _stat) hurts too much, then don't do it (use stat instead, it's standardized). -- Matthias Andree -- 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: incomplete/corrupted setup.exe
George Barrick wrote on 2010-03-14: 2010.03.14.12:14:09 EST Hello Cygwin, The output from 'wget -S' was: $ wget -S http://cygwin.com/setup.exe --2010-03-14 12:08:43-- http://cygwin.com/setup.exe Resolving cygwin.com... 209.132.180.131 Connecting to cygwin.com|209.132.180.131|:80... connected. HTTP request sent, awaiting response... HTTP/1.0 200 OK Server: Web Filter Blocked Page This is inconsistent and bogus. Someone writing the filter software should read the HTTP standards. The Proxy blocks the page yet returns HTTP/1.0 200 OK, but should use a code >= 400, I's think that 502 Bad Gateway and 403 Forbidden are the best choices here. The setup.exe file that I received was actually a web-page with some embedded scripts from the Cymphonix group. They ask you to link to an e-mail page if you wish to report a mis-characterized page or resource. I sent the e-mail, but I'm not expecting a response. I've been through it before; they just ignore the requests. Then a complaint to those who are responsible for setting up or subscribing to this Cymphonix stuff might be in order, to tell them it's not working properly, and that it corrupts data. Depending on exact circumstances and legislation, this may even be illegal. -- Matthias Andree -- 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: recvfrom + MSG_PEEK = broken?
Am 23.03.2010, 07:24 Uhr, schrieb Charles Wilson:
On 3/22/2010 4:33 PM, Warren Young wrote:
On 3/22/2010 5:03 AM, Corinna Vinschen wrote:
The last time I had problems with MSG_PEEK was back in 2006. Curious
how seldomly it's used, apparently.
Peeking is evil:
http://tangentsoft.net/wskfaq/newbie.html#peeking
The extra kernel context switch problem isn't Windows-specific, so
peeking should be avoided in all code for that reason alone.
That's all well and good, but I'm not writing new code; I also see no
need to rewrite xinetd from the ground up, as that'd be what it would
take to avoid the use of MSG_PEEK. I'm simply trying to get existing
code, which uses normal POSIX functions in their normal, documented way,
to work properly. recvfrom has a specific, documented POSIX behavior,
and that behavior includes MSG_PEEK. Cygwin's implementation didn't
work before; now it does. That's a plus, no matter what some random
webpage might think about the function.
FWIW, fetchmail has had a Cygwin-specific workaround for a
recvfrom(...MSG_PEEK)/read sequence for ages (since 2001, to be precise).
Perhaps a similar workaround might want to migrate into Cygwin, unless
it's already there (if so, I'd like to know the version so I can make this
workaround depend on the Cygwin version).
The code was originally from Jason Tishler (see URL embedded in the
comment) and is now upstream in socket.c, full reference:
<http://gitorious.org/fetchmail/fetchmail/blobs/master/socket.c> ll.
999ff. currently:
#ifdef __CYGWIN__
/*
* Workaround Microsoft Winsock recv/WSARecv(..., MSG_PEEK) bug.
* See http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html
* for more details.
*/
static ssize_t cygwin_read(int sock, void *buf, size_t count)
{
...
and tries to do a 2nd read to fill "count" in.
Err...sure. "I want to design my networking stack in such a way that it
can't support a specific POSIX call, so I'll blame POSIX"
Rumors have it that WinSock was derived from a BSD stack, and relevant
TCP/IP fingerprints supported that. I never bothered to check though.
--
Matthias Andree
--
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: Setup.ini file for Silent Install
Am 26.03.2010 10:25, schrieb Christoph Herdeg: > Is there eventually a possibility of someone explaining to me why Jonathan > used my incredibly complex and hard to maintain method rather than > following Daves eloquent advice?!? > Although it's so funny that my message cam *after* somebody telling him how > to do this with setup.exe?!? Message propagation times may not be the same for everyone - greylisting; server hiccups and retry schedules, and other reasons might cause this... -- Matthias Andree -- 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: "svn --version" halts in 1.7.2-2
Am 26.03.2010 10:32, schrieb Corinna Vinschen: > On Mar 26 15:40, Nayuta Taga wrote: >> Hi, >> >> "svn --version" hals in 1.7.2-2 on both Windows7 and XP. >> The log is following: >> >> $ uname -a >> CYGWIN_NT-6.1 yumiko 1.7.2(0.225/5/3) 2010-03-24 21:12 i686 Cygwin >> $ env LANG=C svn --version >> svn, version 1.6.9 (r901367) >>compiled Feb 10 2010, 10:34:02 >> >> Copyright (C) 2000-2009 CollabNet. >> Subversion is open source software, see http://subversion.tigris.org/ >> This product includes software developed by CollabNet >> (http://www.Collab.Net/). >> >> The following repository access (RA) modules are available: >> >> * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. >> - handles 'http' scheme >> - handles 'https' scheme >> * ra_svn : Module for accessing a repository using the svn network protocol. >> - with Cyrus SASL authentication >> - handles 'svn' scheme >> * ra_local : Module for accessing a repository on local disk. >> - handles 'file' scheme >> * ra_serf : Module for accessing a repository via WebDAV protocol using serf. >> - handles 'http' scheme >> - handles 'https' scheme >> >> (the shell prompt is not shown, and control+C has no effect) > > Works for me. BLODA? Hangs for me too. Win 7 32-bit with Cygwin 1.7.2-2, Sophos Endpoint Security and Control 9.0.4 with the Anti-Virus service disabled. strace log at http://129.217.163.1/%7E%6D%61/tmp/svn_version-hang.txt.xz gdb is inconclusive; if I run "gdb svn" and "b main", gdb breaks at exit and then goofs up down deep in exit. If I use kill -9, gdb breaks again and I get: (gdb) bt #0 0x in ?? () #1 0x77ca5e4c in ntdll!ZwWriteRequestData () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x75e66872 in KERNELBASE!GetProcessId () from /cygdrive/c/Windows/system32/KernelBase.dll #3 0x0002 in ?? () #4 0x0022c81c in ?? () #5 0x0001 in ?? () #6 0x in ?? () I guess this doesn't help. Interesting observation: run "gdb svn", "b exit", "run --version"; gdb breaks: ... * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Breakpoint 1, 0x61112df7 in exit () from /usr/bin/cygwin1.dll (gdb) bt #0 0x61112df7 in exit () from /usr/bin/cygwin1.dll #1 0x61006e7b in _cygwin_exit_return () from /usr/bin/cygwin1.dll #2 0x in ?? makes some sense, but then if you run "s" or "c", it hangs. So it appears as though the hang happened in exit() somewhere. Same with svn --help. This appears to be specific to svn; svnlook, avnadmin aren't affected on my computer. This is the unified diff of "cygcheck /usr/bin/svnadmin" vs. "cygcheck /usr/bin/svn": @@ -1,4 +1,7 @@ -C:\cygwin\bin\svnadmin.exe +C:\cygwin\bin\svn.exe + C:\cygwin\bin\cygsvn_client-1-0.dll +C:\cygwin\bin\cygsvn_ra-1-0.dll + C:\cygwin\bin\cygsvn_ra_local-1-0.dll C:\cygwin\bin\cygsvn_repos-1-0.dll C:\cygwin\bin\cygsvn_fs-1-0.dll C:\cygwin\bin\cygsvn_fs_base-1-0.dll @@ -56,3 +59,13 @@ C:\cygwin\bin\cygsvn_fs_util-1-0.dll C:\cygwin\bin\cygdb-4.2.dll C:\cygwin\bin\cygsvn_fs_fs-1-0.dll + C:\cygwin\bin\cygsvn_ra_neon-1-0.dll +C:\cygwin\bin\cygneon-27.dll + C:\cygwin\bin\cygcrypto-0.9.8.dll + C:\cygwin\bin\cygssl-0.9.8.dll + C:\cygwin\bin\cygsvn_ra_serf-1-0.dll +C:\cygwin\bin\cygserf-0-0.dll + C:\cygwin\bin\cygsvn_ra_svn-1-0.dll +C:\cygwin\bin\cygsasl2-2.dll +C:\cygwin\bin\cygsvn_wc-1-0.dll + C:\cygwin\bin\cygsvn_diff-1-0.dll Might of the additional libraries may have regressed? From the strace log, I suspect cygsasl2, which itself loads libraries, for instance /lib/sasl2/cygplain-2.dll and /lib/sasl2/cygsasldb-2.dll on my computer (cygsasldb-2.dll is the last before the hang). I've also run rebaseall, to no avail. HTH -- Matthias Andree svn_version-hang.txt.xz Description: Binary data -- 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: "svn --version" halts in 1.7.2-2
Am 26.03.2010 11:54, schrieb Corinna Vinschen: > On Mar 26 11:12, Matthias Andree wrote: >> Am 26.03.2010 10:32, schrieb Corinna Vinschen: >> > On Mar 26 15:40, Nayuta Taga wrote: >> >> Hi, >> >> >> >> "svn --version" hals in 1.7.2-2 on both Windows7 and XP. >> >> The log is following: >> >> [...] >> >> (the shell prompt is not shown, and control+C has no effect) >> > >> > Works for me. BLODA? >> >> Hangs for me too. Win 7 32-bit with Cygwin 1.7.2-2, Sophos Endpoint Security >> and >> Control 9.0.4 with the Anti-Virus service disabled. > > I've tested on W7 32-bit as well. Works still fine every time I try, > in a console window as well as in mintty. > >> gdb is inconclusive; if I run "gdb svn" and "b main", gdb breaks at exit and >> then goofs up down deep in exit. If I use kill -9, gdb breaks again and I >> get: >> >> (gdb) bt >> #0 0x in ?? () >> #1 0x77ca5e4c in ntdll!ZwWriteRequestData () >>from /cygdrive/c/Windows/system32/ntdll.dll >> #2 0x75e66872 in KERNELBASE!GetProcessId () >>from /cygdrive/c/Windows/system32/KernelBase.dll >> #3 0x0002 in ?? () >> #4 0x0022c81c in ?? () >> #5 0x0001 in ?? () >> #6 0x in ?? () >> >> I guess this doesn't help. > > You should probably at least switch to thread 1. Oh right (sorry, I usually write/debug single-threaded Unixy applications...) So let's dig a little deeper: Program received signal SIGKILL, Killed. 0x in ?? () (gdb) info threads 2 thread 6116.0x15f8 0x75849617 in RaiseException () from /cygdrive/c/Windows/system32/KernelBase.dll * 1 thread 6116.0x140c 0x775764f4 in ntdll!LdrFindResourceEx_U () from /cygdrive/c/Windows/system32/ntdll.dll warning: Couldn't restore frame in current thread, at frame 0 0x775764f4 in ntdll!LdrFindResourceEx_U () from /cygdrive/c/Windows/system32/ntdll.dll (gdb) thread 1 [Switching to thread 1 (thread 6116.0x140c)]#0 0x775764f4 in ntdll!LdrFindResourceEx_U () from /cygdrive/c/Windows/system32/ntdll.dll (gdb) bt #0 0x775764f4 in ntdll!LdrFindResourceEx_U () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x77575e4c in ntdll!ZwWriteRequestData () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x75846872 in KERNELBASE!GetProcessId () from /cygdrive/c/Windows/system32/KernelBase.dll #3 0x0002 in ?? () #4 0x0022c81c in ?? () #5 0x0001 in ?? () #6 0x in ?? () (gdb) thread 2 [Switching to thread 2 (thread 6116.0x15f8)]#0 0x75849617 in RaiseException () from /cygdrive/c/Windows/system32/KernelBase.dll (gdb) bt #0 0x75849617 in RaiseException () from /cygdrive/c/Windows/system32/KernelBase.dll #1 0x7585d549 in OutputDebugStringA () from /cygdrive/c/Windows/system32/KernelBase.dll #2 0x40010006 in ?? () #3 0x in ?? () (gdb) -- Matthias Andree -- 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: "svn --version" halts in 1.7.2-2
Am 26.03.2010 12:23, schrieb Dave Korn: > On 26/03/2010 10:12, Matthias Andree wrote: > >> Might of the additional libraries may have regressed? From the strace log, I >> suspect cygsasl2, which itself loads libraries, for instance >> /lib/sasl2/cygplain-2.dll and /lib/sasl2/cygsasldb-2.dll on my computer >> (cygsasldb-2.dll is the last before the hang). > > I had mysterious problems with svn once which didn't go away until I got rid > of all the sasl2 stuff from my installation, so this theory is worth pursuing. Doesn't look like this were a viable approach today; if I read cygcheck output correctly, svn depends libserf which in turn depends on sasl2... -- Matthias Andree -- 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: "svn --version" halts in 1.7.2-2
Am 27.03.2010 00:15, schrieb David Rothenberger: > On 3/26/2010 2:07 PM, Corinna Vinschen wrote: >> On Mar 26 11:12, David Rothenberger wrote: >>> On 3/26/2010 2:32 AM, Corinna Vinschen wrote: >>>> On Mar 26 15:40, Nayuta Taga wrote: >>>>> "svn --version" hals in 1.7.2-2 on both Windows7 and XP. >>> [snip] >>>> >>>> Works for me. BLODA? >>> >>> I'm able to reproduce this on one of my three Windows XP machines. >>> Ironically, the only one without a Symantec product installed. >>> >>> On 3/26/2010 4:23 AM, Dave Korn wrote: >>>> I had mysterious problems with svn once which didn't go away until I got >>>> rid >>>> of all the sasl2 stuff from my installation, so this theory is worth >>>> pursuing. >>> >>> I recompiled without sasl2 support directly in svn and that fixed the >>> problem for me. This didn't require disabling serf, by the way. >>> >>> I'm not sure why this is hanging on some machines and not others. I see >>> in Process Explorer there's a UDP connection related to sasl2 open when >>> the process is hanging, but I haven't had time to investigate further. >> >> There's an open UDP connection when calling `svn --version'??? > > Yup. Here's the thread stack at the time the connection was created: > > !connect+0x53 > !cygwin_internal+0x2b0d5 > !setlogmask+0xce8 > !setlogmask+0xdff > !aclcheck+0x11836 > !sasl_log+0x123 > !sasl_get_plugin+0xa6 > !sasl_load_plugins+0x2e3 > !sasl_client_init+0xdf > !svn_ra_svn__sasl_init+0x9c > !svn_atomic__init_once+0x49 > !svn_ra_svn__sasl_init+0x22 > !svn_ra_print_modules+0x5d > > The sasl_log thing caused me to check /var/log/messages. Here's what > I found: > > Mar 26 15:53:28 localhost unable: to dlopen > /usr/lib/sasl2/cygdigestmd5-2.dll: No such file or directory > Mar 26 15:53:28 localhost unable: to dlopen /usr/lib/sasl2/cygotp-2.dll: No > such file or directory > > Which is weird, because those DLLs are there. So, next I tried an > strace. I noticed that the /usr/lib/sasl2/*.la files were being > opened, which also seemed weird. > > So I tried uninstalling libsasl2-devel. It worked! No hang! This > seems to be the key. The sasl2 initialization appears to hang if the > -devel package is installed, otherwise it works fine. > >> I just tested on an up-to-date XP SP3 machine and it also works fine >> there, no hangs. > > Works fine for me on all machines without libsasl2-devel. BTW, it > appears Matthias also had the -devel package installed, because his > strace also shows attempts to open the .la files in /usr/lib/sasl2. > Indeed I used to have libsasl2-devel installed. For me, too, removing libsasl2-devel has fixed the hang. -- Matthias Andree -- 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: "svn --version" halts in 1.7.2-2
Am 27.03.2010 03:15, schrieb Eliot Moss:
> On 3/26/2010 10:12 PM, David Rothenberger wrote:
>> On 3/26/2010 5:57 PM, Eliot Moss wrote:
>>> My Windows 7 system hands on svn --version also, but
>>> produces no messages to /var/log/messages. I tried
>>> uninstalling libsasl2-devel but doing so had no effect.
>>>
>>> Regard -- Eliot Moss
>>
>> What happens if you rename /usr/lib/sasl2 to something else?
>>
>> % mv /usr/lib/sasl2 /usr/lib/sasl2.disabled
>> % svn --version
>
> A great thought, David! Works perfectly!
>
> Not sure what else might depend on it, but it's an ok
> work-around for the moment, and possibly a good clue to
> the maintainers ...
Probably the record that some /usr/lib/sasl2 stuff got installed was lost
somehow. A couple of days ago, I found my computer with an inconsistent setup
database (which showed a lot fewer files/packages than were actually installed),
so I got very few of the offered package updates displayed. I investigated and
came up with a script to fix this (consider this version 0.0.1 and under GNU GPL
v3) state (see below).
I'd also appreciate if setup.exe recorded file hashes so I can see which files
have been altered since initial installation with a (to be written) cygcheck. I
know, volunteer efforts and spare time, but I'd still mention it.
Here's the script. Crude, works for me in a particular situation, so no
warranties whatsoever (you're free not to use it):
---
#! /bin/bash
# repair-cygwin.sh - (C) 2010 Matthias Andree
set -eu
if [ $'\x20' != ' ' ] ; then
echo "Your shell does not understand \$'...' - trying bash"
exec /bin/bash --norc --noprofile "$0"
fi
unset LC_COLLATE
unset LC_CTYPE
unset LANG
export LC_ALL=C
export PATH=/bin:/usr/bin
echo "==> Checking for broken packages:"
# obtain list of broken packages:
cygcheck -c | tail -n +3 | egrep -v $'OK\r?$' | awk '{ print $1}' >/tmp/need
echo "Broken packages: $(cat /tmp/need | tr '
' ','|sed 's/,$//')"
echo "==> Checking for missing packages:"
# obtain list of packages that got installed
(cd /etc/setup/ && ls *.lst.gz ) | sed 's/.lst.gz$//' | sort >/tmp/pkgs
# obtain list of packages that Cygwin believes are installed
cygcheck -c -d | tail -n +3 | awk '{ print $1}' | sort >/tmp/have
# obtain list of missing packages:
miss="$(comm -3 /tmp/pkgs /tmp/have)"
printf "%s" "$miss" >>/tmp/need
echo "Missing packages: $(echo "$miss" | tr '
' ',' | sed 's/,$//')"
echo "==> Done."
if [ -z "$(cat /tmp/need)" ] ; then
echo "No packages found missing or broken."
exit 0
fi
# drop packages from installed.db so that they get reinstalled:
for i in $(sort -u /tmp/need) ; do
grep -v "^$i " /etc/setup/installed.db >/etc/setup/i && mv /etc/setup/i
/etc/setup/installed.db
done
# now go
ok=0
for i in $(id -G) ; do
if [ "_$i" = _0 ] ; then ok=1 ; fi
done
cmd="./setup.exe -n -q -P $(sort -u /tmp/need | tr '
' ',' | sed 's/,$//')"
if [ $ok = 1 ] ; then
echo "==> Downloading setup.exe"
wget -nv -N http://cygwin.com/setup.exe http://cygwin.com/setup.exe.sig
echo "==> Verifying setup.exe signature"
gpg --verify setup.exe.sig setup.exe
echo "==> Running setup.exe"
chmod +x setup.exe
$cmd
else
echo "Now run the following command from an Administrator shell,"
echo "after you've downloaded and verified Cygwin's setup.exe:"
echo "$cmd"
fi
---
--
Matthias Andree
--
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: "svn --version" halts in 1.7.2-2
Am 27.03.2010 17:37, schrieb Andy Koppe: > Charles Wilson: >> Hmm. I remember having transient problems with svn and many of the >> 1.7.0 snapshots, but they were intermittent and I had bigger fish to >> fry. I don't recall any issues with 1.7.1, nor am I having any trouble >> with 1.7.2. However, I would not be surprised if >> >> (a) the "problem" is some intermittent interaction between >> cygwin-1.7.x's completely redesigned file name handling and an old, >> statically-linked, compiled during the 1.5.x era, libltdl >> >> (b) the reason you didn't see it in 1.7.1 was just that -- it's >> intermittent, and you didn't HAPPEN to see it during that 3-month window. >> >> (c) if libsasl2 had been linked against the DLL version of cygltdl, then >> perhaps none of this would have happened -- since I try to keep the >> officially distributed libtool more-or-less up to date, and rigorously >> tested. > > Not that I understand any of the details, but there've been changes to > atexit() handling in 1.7.2; perhaps they're something to do with this. > Might also tie into the thread about rxvt not exiting. At least that would explain why I can breakpoint exit() with gdb tracing svn, and it hangs if I continue into exit(). -- Matthias Andree -- 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: "svn --version" halts in 1.7.2-2
Peter Rosin wrote on 2010-03-28: It could be that /usr/lib/sasl2/libsasldb.la lists /usr/lib/libdb-4.2.la as a dependency_libs. libdb-4.2.la may or may not be installed (it's in libdb4.2-devel which I don't have installed) and if it's missing libltdl might be "confused". If that's indeed the case, is it easy to add the needed dependency to the libsasl2-devel package? That does not help - I've always had libdb4.2-devel installed (including /usr/lib/libdb-4.2.la which at first glance seems complete). -- Matthias Andree -- 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: "svn --version" halts in 1.7.2-2
Christopher Faylor wrote on 2010-03-28: On Sun, Mar 28, 2010 at 11:53:44AM -0400, Christopher Faylor wrote: On Sun, Mar 28, 2010 at 04:34:27PM +0200, Matthias Andree wrote: At least that would explain why I can breakpoint exit() with gdb tracing svn, and it hangs if I continue into exit(). I can duplicate the problem and am looking into it. This should be fixed in the current snapshot at http://cygwin.com/snapshots/ The new .dll (-0328) Works for me, thanks! -- Matthias Andree -- 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: scp no longer reports incremental progress
Christopher Faylor wrote on 2010-03-31: On Mon, Mar 29, 2010 at 06:14:39PM -0400, Christopher Faylor wrote: On Mon, Mar 29, 2010 at 06:12:53PM -0400, Charles Wilson wrote: On 3/29/2010 6:09 PM, Jim Reisert AD1C wrote: I am running the latest Cygwin (1.7.2) and ssh. I notice that scp (from local to remote host) no longer shows an incremental progress bar. It just reports 100% completion immediately, then I have to wait until the copy is actually done. Sink: C0644 11015296 dx4wawd.zip dx4wawd.zip 100% 11MB 10.5MB/s 00:00 Hmm...same behavior here. Didn't we see this behavior before, about a year ago? I think what fixed it back then was some cgf magic in the socket fhandler innards. Uh-oh. One of the changes between 1.7.1 and 1.7.2 was more socket work. Actually, I think it was pipe related. And, it was. I removed what I thought was an stupid function. As it turns out the function was needed but it just wasn't working quite right. Today's snapshot, uploaded a few minutes ago, should fix the problem. Euh, 20100331 seems to introduce regressions for me compared to 20100328. scp now seems broken for me, $ scp -v somefile u...@example.org:/tmp/ Executing: program /usr/bin/ssh host example.org, user user, command scp -v -t -- /tmp/ and often just hangs there, while PuTTY's pscp and interactive ssh to the same host + login works just fine, and also if I'm using the 20100328 snapshot. With gdb attached, it succeeds once in a while. -- Matthias Andree -- 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: fopen with "a+" does not respect setting file read position to start of file
Bengt-Arne Fjellner wrote on 2010-04-01:
On 2010-04-01 11:06 AM, Brebner, Gavin wrote:
We hit a problem in a code, and narrowed it down to a test case that
does :
while (cnt) {
f=fopen(host_file, "a+");
if (!f)
perror("dup_host_file: Could not open hostfile");
/* rewind(f); */
while (cnt) {
int ret=fscanf(f, "%s", line);
if (ret != EOF) {
fprintf(f, "%s\n", line);
cnt--;
dup++;
}
}
fclose(f);
In earlier versions of cygwin we have, this works fine, however in the
recently installed
versions, it no longer works. It seems that fopen(host_file, "a+") is
NOT positioning the
read position at the start of the file as it should. Adding an explicit
rewind(f) is a
work around.
Well if that worked previously it was a bug.
Not a Cygwin defect, but an application bug, and what Gavin named "work
around" is actually the right fix.
POSIX explicitly states that the initial position beginning/end of file in
append mode is implementation-defined, and the Cygwin documentation
doesn't make promises either way. Linux and FreeBSD document BOF and EOF,
respectively.
From the manual for fopen:
``a+'' Open for reading and writing. The file is created if it
does not exist. The stream is positioned at the
end of the file. Subsequent writes to the file will
always end up at the then current end of file, irre-
spective of any intervening fseek(3) or similar.
Irrelevant, as that is neither from POSIX nor from cygwin-doc-1.5-1.
--
Matthias Andree
--
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: scp no longer reports incremental progress
Am 01.04.2010 16:17, schrieb Corinna Vinschen: > On Apr 1 14:00, Matthias Andree wrote: >> Christopher Faylor wrote on 2010-03-31: >> >> >On Mon, Mar 29, 2010 at 06:14:39PM -0400, Christopher Faylor wrote: >> >>On Mon, Mar 29, 2010 at 06:12:53PM -0400, Charles Wilson wrote: >> >>>On 3/29/2010 6:09 PM, Jim Reisert AD1C wrote: >> >>>>I am running the latest Cygwin (1.7.2) and ssh. >> >>>> >> >>>>I notice that scp (from local to remote host) no longer shows an >> >>>>incremental progress bar. It just reports 100% completion >> >>>>immediately, then I have to wait until the copy is actually done. >> >>> >> >>>>Sink: C0644 11015296 dx4wawd.zip >> >>>>dx4wawd.zip >> >>>> 100% 11MB 10.5MB/s 00:00 >> >>> >> >>>Hmm...same behavior here. Didn't we see this behavior before, about a >> >>>year ago? I think what fixed it back then was some cgf magic in the >> >>>socket fhandler innards. >> >>> >> >>>Uh-oh. One of the changes between 1.7.1 and 1.7.2 was more socket work. >> >> >> >>Actually, I think it was pipe related. >> > >> >And, it was. I removed what I thought was an stupid function. As it >> >turns out the function was needed but it just wasn't working quite >> >right. >> > >> >Today's snapshot, uploaded a few minutes ago, should fix the problem. >> >> Euh, 20100331 seems to introduce regressions for me compared to 20100328. >> scp now seems broken for me, >> >> $ scp -v somefile u...@example.org:/tmp/ >> Executing: program /usr/bin/ssh host example.org, user user, command >> scp -v -t -- /tmp/ >> >> and often just hangs there, while PuTTY's pscp and interactive ssh >> to the same host + login works just fine, and also if I'm using the >> 20100328 snapshot. > > Strange, I'm trying that, too, and it works every time for me. > Is your remote box a Cygwin box or some foreign OS? remote is openSUSE 11.2 on 32-bit i686 with OpenSSH 5.2. -- Matthias Andree -- 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: scp no longer reports incremental progress
Am 01.04.2010 16:43, schrieb Christopher Faylor: > On Thu, Apr 01, 2010 at 02:00:42PM +0300, Matthias Andree wrote: >>Christopher Faylor wrote on 2010-03-31: >> >>> On Mon, Mar 29, 2010 at 06:14:39PM -0400, Christopher Faylor wrote: >>>> On Mon, Mar 29, 2010 at 06:12:53PM -0400, Charles Wilson wrote: >>>>> On 3/29/2010 6:09 PM, Jim Reisert AD1C wrote: >>>>>> I am running the latest Cygwin (1.7.2) and ssh. >>>>>> >>>>>> I notice that scp (from local to remote host) no longer shows an >>>>>> incremental progress bar. It just reports 100% completion >>>>>> immediately, then I have to wait until the copy is actually done. >>>>> >>>>>> Sink: C0644 11015296 dx4wawd.zip >>>>>> dx4wawd.zip >>>>>>100% 11MB 10.5MB/s 00:00 >>>>> >>>>> Hmm...same behavior here. Didn't we see this behavior before, about a >>>>> year ago? I think what fixed it back then was some cgf magic in the >>>>> socket fhandler innards. >>>>> >>>>> Uh-oh. One of the changes between 1.7.1 and 1.7.2 was more socket work. >>>> >>>> Actually, I think it was pipe related. >>> >>> And, it was. I removed what I thought was an stupid function. As it >>> turns out the function was needed but it just wasn't working quite >>> right. >>> >>> Today's snapshot, uploaded a few minutes ago, should fix the problem. >> >>Euh, 20100331 seems to introduce regressions for me compared to 20100328. >>scp now seems broken for me, >> >>$ scp -v somefile u...@example.org:/tmp/ >>Executing: program /usr/bin/ssh host example.org, user user, command scp >>-v -t -- /tmp/ >> >>and often just hangs there, while PuTTY's pscp and interactive ssh to the >>same host + login works just fine, and also if I'm using the 20100328 >>snapshot. >> >>With gdb attached, it succeeds once in a while. > > How big is "somefile" and where is "example.org"? Is it a local > machine? In another country/state/continent? What kind of system is > it? As written to Corinna, 32-bit i686 openSUSE 11.2 Linux fully patched with preinstalled openSSH 5.2. Few MB, or 1.X MB. example.org is behind an ADSL line which is ~12 Mbit/s in the direction where I'm trying to copy and ~0.6 Mbit/s in the opposite direction. Note that with 20100328 I sort of "immediately" get the SSH debug trace, whereas there is no output at all with 20100331. (on Windows 7 Professional 32-bit German which itself sits on a 100 Mbit/s firehose). 12 hops, 48 ms (the first 10 hops take 7 ms, 11 hops 14 ms, then the typical DSL interleaving on the last hop). -- Matthias Andree -- 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: fopen with "a+" does not respect setting file read position to start of file
Eric Blake wrote on 2010-04-01:
On 04/01/2010 05:53 AM, Matthias Andree wrote:
Well if that worked previously it was a bug.
Not a Cygwin defect, but an application bug, and what Gavin named "work
around" is actually the right fix.
POSIX explicitly states that the initial position beginning/end of file
in append mode is implementation-defined, and the Cygwin documentation
doesn't make promises either way. Linux and FreeBSD document BOF and
EOF, respectively.
I agree that it is not a cygwin bug. And I actually prefer Linux'
interpretation of BOF, since it matches with the POSIX requirement that
open(,O_APPEND|O_RDWR) be positioned at offset 0 and not at the end (it
is only fopen that is allowed, but not required, to be at the end). In
fact, the release of m4 1.4.10 worked on cygwin and Linux but was broken
on BSD because of this very portability pitfall.
Preference seconded; Solaris 10 for instance also comes up with
ftell[o](fopen("nonemptyfile", "a+")) == 0.
The FreeBSD argument (in the libc sources) is that their approach
applications gets use ftell[o]() right - and how this isn't reliable at
the same time:
/*
* When opening in append mode, even though we use O_APPEND,
* we need to seek to the end so that ftell() gets the right
* answer. If the user then alters the seek pointer, or
* the file extends, this will fail, but there is not much
* we can do about this. (We could set __SAPP and check in
* fseek and ftell.)
*/
if (oflags & O_APPEND)
(void)_sseek(fp, (fpos_t)0, SEEK_END);
(<http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fopen.c?rev=1.14>
bottom)
--
Matthias Andree
--
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: scp no longer reports incremental progress
Corinna Vinschen wrote on 2010-04-01: On Apr 1 18:17, Matthias Andree wrote: Am 01.04.2010 16:43, schrieb Christopher Faylor: > On Thu, Apr 01, 2010 at 02:00:42PM +0300, Matthias Andree wrote: >>Euh, 20100331 seems to introduce regressions for me compared to 20100328. >>scp now seems broken for me, >> >>$ scp -v somefile u...@example.org:/tmp/ >>Executing: program /usr/bin/ssh host example.org, user user, command scp >>-v -t -- /tmp/ >> >>and often just hangs there, while PuTTY's pscp and interactive ssh to the >>same host + login works just fine, and also if I'm using the 20100328 >>snapshot. >> >>With gdb attached, it succeeds once in a while. > > How big is "somefile" and where is "example.org"? Is it a local > machine? In another country/state/continent? What kind of system is > it? As written to Corinna, 32-bit i686 openSUSE 11.2 Linux fully patched with preinstalled openSSH 5.2. Few MB, or 1.X MB. example.org is behind an ADSL line which is ~12 Mbit/s in the direction where I'm trying to copy and ~0.6 Mbit/s in the opposite direction. Note that with 20100328 I sort of "immediately" get the SSH debug trace, whereas there is no output at all with 20100331. (on Windows 7 Professional 32-bit German which itself sits on a 100 Mbit/s firehose). 12 hops, 48 ms (the first 10 hops take 7 ms, 11 hops 14 ms, then the typical DSL interleaving on the last hop). Just tried a slow line as well, multiple times. It still works fine for me with DSL upload speed of 0.6 Mbit/s, remote is cygwin.com which is running some Linux as well. 10 hops. Are you sure you didn't suffer from some other problem, like multiple Cygwin versions or something? I shut down all Cygwin processes (ps -al only listed itself) and replaced cygwin1.dll before doing the trials. What else would I have to do to be sure? Or did I miss replacing other parts of the system for the trial? -- Matthias Andree -- 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: scp no longer reports incremental progress
So let's get the network out of the picture. I also observe: 20100328, no processes running, ash -c "rebaseall -v" starts logging dll names after < 1 s. 20100331, same situation, ash -c "rebaseall -v" shows no output. Note I'm not waiting very long, if the system has become an order of magnitude slower or goof up flushing console output that would also count as regression. I've run experiments in mintty as well as cmd.exe windows. -- Matthias Andree -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.3-1
Tim McDaniel wrote on 2010-04-05: On Mon, 5 Apr 2010, Christopher Faylor wrote: On Mon, Apr 05, 2010 at 05:42:05PM +1000, Rurik Christiansen wrote: * How do I know what the current release is ? (e.g. is there something like /etc/redhat-release or whatever ? The docs mention /var/log/setup ... but is not clear at all) ... Otherwise, as Dave Korn suggests, you can *read the website*. I suppose that "/etc/redhat-release" is not as well-known a concept as he or I had thought. As I understand it, it's a file that's maintained by the Redhat installation software to show, in an easy human-readable way, what is currently installed on the running system. It is only updated by new installs run on the machine. I think that some other distributions put something in /etc/motd. There's the LSB, Linux Standards Base, and it supports a "lsb_release" command, try "lsb_release -a" for a start, here a few samplers: LSB Version: core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:core-3.2-ia32:core-4.0-ia32:core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-3.2-noarch:core-4.0-noarch:cxx-3.0-ia32:cxx-3.1-ia32:cxx-3.2-ia32:cxx-4.0-ia32:cxx-3.0-noarch:cxx-3.1-noarch:cxx-3.2-noarch:cxx-4.0-noarch:printing-3.2-ia32:printing-4.0-ia32:printing-3.2-noarch:printing-4.0-noarch Distributor ID: Ubuntu Description:Ubuntu 8.04.4 LTS Release:8.04 Codename: hardy LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:cxx-4.0-ia32:cxx-4.0-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch Distributor ID: Ubuntu Description:Ubuntu 9.10 Release:9.10 Codename: karmic LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-ia32:core-3.2-ia32:core-4.0-ia32:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch Distributor ID: SUSE LINUX Description:openSUSE 11.2 (i586) Release: 11.2 Codename: n/a -- Matthias Andree -- 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: scp no longer reports incremental progress
Chris Sutcliffe wrote on 2010-04-06: On 2 April 2010 10:06, Matthias Andree wrote: So let's get the network out of the picture. I also observe: 20100328, no processes running, ash -c "rebaseall -v" starts logging dll names after < 1 s. 20100331, same situation, ash -c "rebaseall -v" shows no output. Note I'm not waiting very long, if the system has become an order of magnitude slower or goof up flushing console output that would also count as regression. I've run experiments in mintty as well as cmd.exe windows. Erm Not sure I follow here, was this supposed to be in response to the scp issue or a new topic? Why would you rebase for the scp issue? To scp. scp forks ssh under the hood, and that might fail for obscure reasons, so this is just a safety measure not to report things that would get solved by "rebaseall". -- Matthias Andree -- 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: scp no longer reports incremental progress
Christopher Faylor wrote on 2010-04-02: On Thu, Apr 01, 2010 at 07:21:25PM +0300, Matthias Andree wrote: I shut down all Cygwin processes (ps -al only listed itself) and replaced cygwin1.dll before doing the trials. What else would I have to do to be sure? Or did I miss replacing other parts of the system for the trial? I could never duplicate this problem but I did finally figure out that there were problems by building cygwin with --enable-debugging. The initial tests in the code pointed to some issues with my most recent pipe code refactoring. Could you try the most recent snapshot and see if it solves the problem? I missed the snapshot, but 1.7.3-1 (which appears newer than the latest snapshot) fixes it for me. Thank you. -- Matthias Andree -- 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
Setup 2.693 unable to replace files through reboot
Greetings, I have observed multiple times, and reproduced, that Setup 2.693 overwriting "in-use files" and rebooting WILL NOT replace those in-use files. Notably cygwin1.dll. Windows 7 Pro, 32-bit, with 4 cygrunsrv services (exim, cron, cygserver, sshd). Reproduce: 1. stop services 2. install some cygwin1.dll with a distinct version that you can recognize from "uname -a" (in my case, snapshot 20100331) 3. start services 4. launch setup.exe (version 2.693) 5. pick cygwin-1.7.3-1 for Reinstall 6. next/continue until... 7. setup.exe complains about files in use - cygwin1.dll, retry/continue (continue requires reboot) 8. click continue 9. setup completes, reminds me to reboot 10. reboot 11. uname -a still shows cygwin1.dll 20100331 is in use. What's up? Can I help to debug this? -- Matthias Andree -- 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: Setup 2.693 unable to replace files through reboot
I'll answer two of Dave's postings, I hope this also provides answers to CGF's
questions:
Am 06.04.2010 21:35, schrieb Dave Korn:
> On 06/04/2010 17:23, Matthias Andree wrote:
>
>> 4. launch setup.exe (version 2.693)
>
> As administrator, or as ordinary user?
As Administrator (in fact that's a property of setup.exe).
>> What's up? Can I help to debug this?
>
> Take a look in /var/log/{setup.log,setup.log.full}; there should be error
> messages if it failed to schedule the replace on reboot that might give us a
> clue.
No strikingly obvious failures, quoting setup.log.full (manually shortened a bit
where there were too many successive lines that differed just by file/path
names, marked by ellipsis).
I find the backslash/fwd slash mixes around C:\cygwin\bin euhm, "interesting",
for instance here: "2010/04/06 19:14:11 Scheduled reboot replacement of file
C:\cygwin\bin/cygwin1.dll with C:\cygwin\bin/cygwin1.dll.new".
Dave later asked:
> Hmm. The docs suggest that the replace-on-reboot functionality
>
> a) can't work on network drives
> b) needs write access to the registry key:
> "HKLM\SYSTEM\CurrentControlSet\Control\Session
> Manager\PendingFileRenameOperations"
> c) may fail if "the System volume is a basic volume [ ... and ... ] the
> destination drive or the source drive is located on a dynamic volume"
>
> Any of those apply to you guys?
(a) no, local C:\ drive
(b) no such key exists. FileRenameOperations is an unnamed empty REG_SZ item.
(c) no dynamic volumes involved, everything is in the basic volume C:\ which is
also the system volume.
Nothing in eventvwr.exe is standing out either.
Now the log, hope it helps. Let me know if you need more information;
cygcheck -srhv information available on request.
> 2010/04/06 19:13:38 Starting cygwin install, version 2.693
> 2010/04/06 19:13:38 io_stream_cygfile: fopen(/etc/setup/net-proxy-host)
> failed 2 No such file or directory
> 2010/04/06 19:13:38 io_stream_cygfile: fopen(/etc/setup/net-proxy-port)
> failed 2 No such file or directory
> 2010/04/06 19:13:38 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2
> No such file or directory
> 2010/04/06 19:13:38 Current Directory: C:\cygwin\usr\src
> 2010/04/06 19:13:38 User has backup/restore rights
> 2010/04/06 19:13:38 Changing gid to Administrators
> 2010/04/06 19:13:38 Could not open service McShield for query, start and
> stop. McAfee may not be installed, or we don't have access.
> 2010/04/06 19:13:40 source: network install
> 2010/04/06 19:13:41 root: C:\cygwin binary system
> 2010/04/06 19:13:41 Selected local directory: C:\cygwin\usr\src
> 2010/04/06 19:13:42 net: Direct
> Loaded cached mirror list
> get_url_to_membuf http://cygwin.com/mirrors.lst
> getUrlToStream http://cygwin.com/mirrors.lst
> 2010/04/06 19:13:44 site:
> http://ftp.inf.tu-dresden.de/software/windows/cygwin32/
> get_url_to_membuf
> http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2
> getUrlToStream
> http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2
> get_url_to_membuf
> http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2.sig
> getUrlToStream
> http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2.sig
> Checking MD5 for
> file://C:\cygwin\usr\src/http%3a%2f%2fftp.inf.tu-dresden.de%2fsoftware%2fwindows%2fcygwin32%2f/release/cygwin/cygwin-1.7.3-1.tar.bz2
> MD5 verified OK:
> file://C:\cygwin\usr\src/http%3a%2f%2fftp.inf.tu-dresden.de%2fsoftware%2fwindows%2fcygwin32%2f/release/cygwin/cygwin-1.7.3-1.tar.bz2
> 4e8072d8f7ff578a6aa272fe3b02c427
> Checking MD5 for
> file://C:\cygwin\usr\src/http%3a%2f%2fftp.inf.tu-dresden.de%2fsoftware%2fwindows%2fcygwin32%2f/release/GNOME/_obsolete/glib2/glib2-2.20.4-1.tar.bz2
> MD5 verified OK:
> file://C:\cygwin\usr\src/http%3a%2f%2fftp.inf.tu-dresden.de%2fsoftware%2fwindows%2fcygwin32%2f/release/GNOME/_obsolete/glib2/glib2-2.20.4-1.tar.bz2
> c616cffee0f344c37fd4e045a7a87054
> 2010/04/06 19:14:03 Running preremove script for cygwin
> 2010/04/06 19:14:03 Uninstalling cygwin
> unlink C:\cygwin/etc/defaults/etc/cygserver.conf
> unlink C:\cygwin\bin/cygcheck.exe
...
> rmdir C:\cygwin/usr/include/asm
> rmdir C:\cygwin/usr/include/arpa
> 2010/04/06 19:14:03 Extracting from
> file://C:\cygwin\usr\src/http%3a%2f%2fftp.inf.tu-dresden.de%2fsoftware%2fwindows%2fcygwin32%2f/release/cygwin/cygwin-1.7.3-1.tar.bz2
> Installing file cygfile:///etc/
> Installing file cygfile:///etc/defaults/
> Installing file cygfile:///etc/defaults/etc/
> Installing file cygfile:///etc/defaults/etc/cygserver.conf
> Installing file cygfile:///usr/
> Installing file cygfile:///usr/bin/
> Installing file cygfile:///usr/bin/cygcheck.exe
Re: Setup 2.693 unable to replace files through reboot
a) can't work on network drives b) needs write access to the registry key: "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" c) may fail if "the System volume is a basic volume [ ... and ... ] the destination drive or the source drive is located on a dynamic volume" Further information, this Key appears to exist only if such operations are actually pending. I triggered a re-install of cygwin 1.7.3-1 again, and got this in the key: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] ... "PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,\ 63,00,79,00,67,00,77,00,69,00,6e,00,5c,00,62,00,69,00,6e,00,5c,00,63,00,79,\ 00,67,00,77,00,69,00,6e,00,31,00,2e,00,64,00,6c,00,6c,00,2e,00,6e,00,65,00,\ 77,00,00,00,21,00,5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,63,00,79,00,67,\ 00,77,00,69,00,6e,00,5c,00,62,00,69,00,6e,00,5c,00,63,00,79,00,67,00,77,00,\ 69,00,6e,00,31,00,2e,00,64,00,6c,00,6c,00,00,00,5c,00,3f,00,3f,00,5c,00,43,\ 00,3a,00,5c,00,63,00,79,00,67,00,77,00,69,00,6e,00,5c,00,75,00,73,00,72,00,\ 5c,00,73,00,62,00,69,00,6e,00,5c,00,63,00,79,00,67,00,73,00,65,00,72,00,76,\ 00,65,00,72,00,2e,00,65,00,78,00,65,00,2e,00,6e,00,65,00,77,00,00,00,21,00,\ 5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,63,00,79,00,67,00,77,00,69,00,6e,\ 00,5c,00,75,00,73,00,72,00,5c,00,73,00,62,00,69,00,6e,00,5c,00,63,00,79,00,\ 67,00,73,00,65,00,72,00,76,00,65,00,72,00,2e,00,65,00,78,00,65,00,00,00,00,\ 00 Or, more readably: \??\C:\cygwin\bin\cygwin1.dll.new !\??\C:\cygwin\bin\cygwin1.dll \??\C:\cygwin\usr\sbin\cygserver.exe.new !\??\C:\cygwin\usr\sbin\cygserver.exe However, after a reboot I still have these files: $ ls -l /bin/cygwin1.dll* -rwxr-xr-x 1 Administratoren None 2.5M 2010-04-03 11:29 /bin/cygwin1.dll* -rwxr-xr-x 1 mandree root 2.5M 2010-04-03 11:29 /bin/cygwin1.dll.new* $ ls -l /usr/sbin/cygserver.exe* -rwxr-xr-x 1 mandree root 150K 2010-04-03 11:29 /usr/sbin/cygserver.exe* -rwxr-xr-x 1 mandree root 150K 2010-04-03 11:29 /usr/sbin/cygserver.exe.new* I would have thought that the .new files were gone after the reboot, or these got somewhat more appropriate owners (I always run setup.exe as Administrator, and have it install "for all users")... -- Matthias Andree -- 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
setup.exe 2.693 installation status incompletely shown in Create Icons/Installation Status screen
Setup 2.693 incompletely displays the "Installation Status" warning on the page that also contains two checkboxes under "create Icons" on my Windows 7 machine (Professional, 32-bit, German, Segoe UI 9pt sized font as pre-installed in my Dell design). This can make the importance of the reboot go unnoticed - important for newcomers to Cygwin. The Installation status has one line, the only readable part is "In-use files have been replaced. You need to reboot as soon as possible to", and then aborts. Resizing the Windows does not help. However the complete message would be "In-use files have been replaced. You need to reboot as soon as possible to *activate the new versions. Cygwin may operate incorrectly until you reboot.*" The part in *...* is missing in my display. Screenshot in PNG format available off-list upon request. Also the Copyright mentions "-2009" but I believe there were changes in 2010 already. -- Matthias Andree -- 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: Setup 2.693 unable to replace files through reboot
Am 07.04.2010, 17:46 Uhr, schrieb Eric Blake: On 04/07/2010 09:41 AM, Christopher Faylor wrote: On Wed, Apr 07, 2010 at 01:40:43PM +0200, Corinna Vinschen wrote: I just applied the matching patch. Chris, could you please upload a new setup.exe? Will do. It will probably take me longer than usual since I have to move to using the new libraries that Chuck just implemented. Do we want to incorporate Matthias's patch before the upload? JFTR and for the benefit for those who don't follow cygwin-apps@; I posted a fix there for these two (and a third issue, outdated README file of cygwin's setup) on cygwin-apps@, Corinna applied it, and Christopher stated he'd include it. -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git on cygwin 1.7.2/1.7.4
Am 08.04.2010, 08:11 Uhr, schrieb Christopher Faylor: On Wed, Apr 07, 2010 at 10:43:08PM -0400, Mark Levedahl wrote: On 03/31/2010 09:36 PM, Mark Levedahl wrote: On Tue, Mar 30, 2010 at 08:08:37PM -0400, Mark Levedahl wrote: All of the above connections and i/o processing are done using bog-standard fork, pipe, open, read, write, and associated file commands. Git has no trouble opening all of the processes and pipes under Cygwin 1.7.2. However, in general before the data transfer is complete the demux process issues an error upon getting an incomplete packet (fewer bytes transmitted than declared in the header), and debugging shows the error code of the read() is ENOENT, indicating the pipe or socket has been terminated early. The index-pack process also issues an error due to receipt of an incomplete pack. Given the above, it seems logical the problem is with pipes, and as 1.7.4-1 is has fixes for pipes I tried it out and found a significant improvement: using 1.7.2-1 I got 16 failures out of 20 attempts to clone a 17 MByte repo on localhost, using 1.7.4-1 this is down to 3 failures out of 20 attempts. (1.7.3-1 was not an improvement). And, yet, there were no fixes for pipes in 1.7.4. Not to suggest anything particular to Mark, but rather as a general comment: I wonder how many of the "1.7.X no better" can be attributed to the replace-on-reboot failure up to and including setup 2.693. If people rely on that rather than running "uname -a" or similar, those that were told to reboot may be unaware they're using the older version. -- Matthias Andree -- 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: Setup 2.693 unable to replace files through reboot
Am 08.04.2010, 18:09 Uhr, schrieb Christopher Faylor: On Wed, Apr 07, 2010 at 11:41:43AM -0400, Christopher Faylor wrote: On Wed, Apr 07, 2010 at 01:40:43PM +0200, Corinna Vinschen wrote: I just applied the matching patch. Chris, could you please upload a new setup.exe? Will do. It will probably take me longer than usual since I have to move to using the new libraries that Chuck just implemented. As it turns out, configure did the right thing in finding these libraries once I installed them so I had very few problems. It is nice to have a fast setup.exe build now. Thanks Chuck! The new version is up there now. Thanks. If you had to install further libraries than are mentioned in setup's README source file, it might be a good idea to update that file. I haven't audited it when I updated the file but just added those I found missing in my patch on -a...@. If further Cygwin packages are required that happened to be pre-installed on my computer, I haven't added them. -- Matthias Andree -- 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 uninstall Cygwin/X (only)
Am 09.04.2010, 07:31 Uhr, schrieb Christopher Faylor: On Fri, Apr 09, 2010 at 04:07:32AM +0100, Dave Korn wrote: On 09/04/2010 02:52, Charles Wilson wrote: Hmm. I wonder if a quick-n-dirty way to "fix" this is to add a right-click context menu to the spinner, so that you can directly choose "Uninstall" without traversing the entire cycle. Rinse and repeat on all the items you want to remove... I am writing a patch to add a right-click context menu to the spinner :) more news in the next couple of days. As long as you're doing that, how about just getting rid of the spinner entirely? IMO, it's an unusual construct. It would probably be better to have a pull-down box or something. While we're at (m)uttering desires, I'd like to propose - which may be more work - keyboard usability. It'd really be nice if I could just hit [-] (uninstall), [+] (install or keep), and trigger reinstall (possibly with r or !). Let's not force users to even more rat-moving and rat-ear-stroking. -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7 man: '-' char in option/switch in man page is not displayed/not encoded well if LANG=C.UTF-8
LiuYan åˆ˜ç ” wrote on 2010-04-19: After moved from Cygwin 1.5 to Cygwin 1.7, the '-' char in switch/option in man page is not displayed. As Cygwin 1.7 have revised to 1.7.5 and cygwin-doc-1.7 is released and this problem still exists, so I decide to figure it out. I have a previous post "Cygwin 1.7: Empty/white-space output when display Chinese characters in GBK charset encoding?" here http://old.nabble.com/Cygwin-1.7%3A-Empty-white-space-output-when-display-Chinese-characters-in-GBK-charset-encoding--ts26774467.html, It seems this problem is similar to that one, because if i set LANG=C.GBK, '-' char will displayed well. But Cygwin 1.7 select UTF-8 as default encoding, is it 'man' does not follow this default encoding? please see the screenshot from old.nabble.com: http://old.nabble.com/file/p28287625/cygwin-1.7-LANG%253DC.UTF-8-man.png cygwin-1.7-LANG%3DC.UTF-8-man.png Short story: groff 1.20.1 seems to fix this. I didn't follow all of this, but basically it's that groff macros would use U+2212 (MINUS SIGN, −) or U+2010 (HYPHEN, -) for "\-" and sometimes "-" when they could be using U+002D (HYPHEN-MINUS, -) for compatibility This has been discussed on the groff lists three years ago, see the thread starting at http://www.mail-archive.com/gr...@gnu.org/msg03657.html for reference. There is also a related groff commit, 2009-01-03 Werner LEMBERG * tmac/an-old.tmac, tmac/doc.tmac: For -Tutf8, map \-, -, ', and ` conservatively to ASCII for the sake of easy cut and paste. While it is meant for cut and paste, it would incidentally also fix searching. Relevant changes are: http://cvs.savannah.gnu.org/viewvc/groff/tmac/an-old.tmac?root=groff&r1=1.61&r2=1.62&sortby=date http://cvs.savannah.gnu.org/viewvc/groff/tmac/doc.tmac?root=groff&r1=1.38&r2=1.39&sortby=date It appears that this got fixed in groff 1.20.1 (I just tried this on 1.7.5(0.225/5/3) with mintty 0.6.1 on Windows 7 Pro German), so an update to groff might fix this for good. -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7 man: '-' char in option/switch in man page is not displayed/not encoded well if LANG=C.UTF-8
Nellis, Kenneth wrote on 2010-04-19: From: LiuYan åˆ˜ç ” Sent: Monday, April 19, 2010 04:51 To: cygwin@cygwin.com Subject: Cygwin 1.7 man: '-' char in option/switch in man page is not displayed/not encoded well if LANG=C.UTF-8 After moved from Cygwin 1.5 to Cygwin 1.7, the '-' char in switch/option in man page is not displayed. ... See the following post for additional information on this issue: http://cygwin.com/ml/cygwin/2010-01/msg00508.html Which misses the point. -- Matthias Andree -- 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: [ANNOUNCEMENT] Updated: groff-1.20.1-1
Am 19.04.2010, 19:39 Uhr, schrieb Christopher Faylor: I've made a new version of groff available for installation. This is an overdue refresh from ftp.gnu.org. It is reputed to fix the problem mentioned here: http://cygwin.com/ml/cygwin/2010-04/msg00745.html That was quick. Thanks a bunch! -- Matthias Andree -- 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: select() hanging after terminal killed
Am 29.04.2010 12:53, schrieb Thomas Wolff: [on closed terminal] > On Linux, select() indicates an exception and EIO. > On SunOS, select() indicates both an exception and input (weird), Not weird, you appear to be misunderstanding select(). An IEEE Std 1003.1 compliant select(): - only states that a subsequent read() will *not block* this includes EOF and error, as they make read() return without blocking) - makes *no statements about success* > On Cygwin, the following is observed: > * EOF is not signalled on read(); rather EIO is indicated right away. > (Maybe not too bad, an application can handle that as well.) > * select() with timeout hangs. > > Especially the latter can hardly be handled by an application. Pointers for workarounds: alarm(), signal(). -- Matthias Andree -- 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: select() hanging after terminal killed
Thomas Wolff wrote on 2010-04-29: On 29.04.2010 13:28, Matthias Andree wrote: Am 29.04.2010 12:53, schrieb Thomas Wolff: [on closed terminal] On Linux, select() indicates an exception and EIO. On SunOS, select() indicates both an exception and input (weird), Not weird, you appear to be misunderstanding select(). An IEEE Std 1003.1 compliant select(): - only states that a subsequent read() will *not block* this includes EOF and error, as they make read() return without blocking) - makes *no statements about success* Oh, right, so apparently Linux is wrong here (since it does not report read availability...). Arguably yes, probably an omission in your system. (Note that older POSIX versions didn't specify that errors means readability). Please look if a relevant bug is filed, and if not, please do so. On Cygwin, the following is observed: * EOF is not signalled on read(); rather EIO is indicated right away. (Maybe not too bad, an application can handle that as well.) * select() with timeout hangs. Especially the latter can hardly be handled by an application. Pointers for workarounds: alarm(), signal(). So I could setup alarm() to get myself signal()ed while waiting in a long sleep(). But the granularity is in seconds only, so this is not a substitute for most use cases typically handled by calling select(). Thanks for the information anyway. Rather than discussing the downsides, you might more efficiently just read the standard, or the system documentation, which would then point you to setitimer(). -- Matthias Andree -- 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: setup messing up ntfs permissions
Am 07.05.2010, 03:40 Uhr, schrieb Vasya Pupkin: Is there any way to stop setup program from messing up NTFS permissions? I don't like how cygwin works with NTFS permissions and therefore it is disabled through /etc/fstab, but setup ignores it and keeps destroying inherited permissions and replacing them with custom ones every time it installs something. I can't vouch for the "don't do it part", but /etc/fstab is ignored because setup.exe doesn't link against cygwin1.dll, thus isn't a Cygwin application in the technical sense (although it is of course essential for Cygwin as a project or installation). -- Matthias Andree -- 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: vfork always fail problem
Am 14.05.2010, 06:29 Uhr, schrieb Huang Bambo:
[ba...@bambo-notebook 4.4.4]$ cat tvfork.c
#include
#include
#include
int main(void)
{
pid_t pid = vfork();
if ( pid > 0 )
{
printf("I'm chield.\n");
_exit(0);
}
else if ( pid == 0 )
{
printf("I'm parent");
}
You've got these swapped. pid == 0 means child, > 0 means parent (so that
it directly has the PID of its child and can later call waitpid()).
You later wrote you've issues with the path; does the same happen if you
use "fork" rather than "vfork"? vfork()ed child processes must not do
anything but modify a variable of type pid_t, call _exit() or exec*().
--
Matthias Andree
--
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: vfork always fail problem
Huang Bambo wrote on 2010-05-19: http://cygwin.com/snapshots/ To the OP: please check it out and verify that it solves your problem. Thanks a lot. I've changed my work directory to a full English name directory and it dosn't matter me. And this problem is first reported by gcc, strange :) . Huang, you - as the person who first saw and documented the problem in public (thank you!) - are in the best position to test it, if you can recreate the original situation (with the GBK(?) directory names). It would be beneficial to all of us, and you would be doing everybody a favour (if you wish, which is your choice), if you could test if the problem reproduces with Cygwin 1.7.5, and goes away with the snapshot. Thank you. Best -- Matthias Andree -- 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 Performance and stat()
Am 06.06.2010, 01:16 Uhr, schrieb Christopher Wingert: I do think out loud with my "team". You are not on it. Agreed! You would rather spend your time ridiculing any possible solution. If only there had been a solution, rather than a loose collection of names (I wouldn't even dare call that ideas) dropped where the Cygwin maintainers - likely based on prior experience - couldn't see how it could have provided all mandatory fields for a POSIX compliant (and no less!) f?stat(). This is what lead to my initial reluctance to do any patch for Cygwin software. A nice way to express that your patch would not stand scrutiny against POSIX anyways. But seriously, Christopher Faylor has been trying to get to a technical discussion, where you avoided his arguments and produced new names of way to solve things again, so let me say this: If you think your post makes you a member of some core team, then you're expecting too much. And this isn't specific to Cygwin. You need to build trust, and that is not achieved by bitching at people and their products, but by answering technical concerns. Meaning that: even if I'm only a Cygwin user, and I'm sometimes disappointed by how slow it is, too, I'm sort of convinced there isn't a cheaper way to get all the required information. And I for one can configure my virus scanner to scan on write or execution, rather than on every read. I can also configure which types of files it's going to scan. For starters, you might try that... -- Matthias Andree -- 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: kerberos tools (kinit, etc) and kerberos-aware openssh in cygwin?
Am 28.04.2009, 18:23 Uhr, schrieb Chris Green : Hi, I have searched through the main mailing list archives and not come up with anything that seems even partially relevant except perhaps a recent email regarding LSA which did not seem to address my exact question. Is it possible for Cygwin to include a kerberos implementation (MIT or Heimdal, for instance) along with kerberos support compiled into the main openssh package? Are there any issues here that I'm not aware of? I've tried to compile the MIT package a couple of times without success but I don't know how much work it would be to get it going? I am aware of several scientists in my field (particle physics research) who rely on Cygwin and their old method of "getting around" was a one-off compile of a very old version of ssh that now does not talk to modern sshd servers properly provided by someone on an as-is basis several years ago. The currently-packaged openssh would work just fine if it were compiled with a set of kerberos libraries. Any help or suggestions for alternatives or existing documentation gratefully received. Hi Chris, the best alternative I'm aware of and I have been using successfully for some weeks now (to the extent possible in PuTTY, which has some rough edges in Unicode and screen line drawing support) is a patched PuTTY snapshot with MIT Kerberos support, courteously provided by Matthew Loar. For details, please see <http://matthew.loar.name/software/putty/>. HTH -- Matthias Andree -- 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: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-47
Am 07.05.2009, 09:26 Uhr, schrieb Magnus Holmgren : By the way, I don't like that setup maximizes the window when on the package selection step. An option somewhere to disable it would be nice. :) But that's actually a useful feature. The default size used to be way too small. -- Matthias Andree -- 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: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
Am 13.05.2009, 16:29 Uhr, schrieb Corinna Vinschen : On May 12 19:37, Corinna Vinschen wrote: On May 13 02:29, IWAMURO Motonori wrote: > I propose that the filename encoding in C locale uses UTF-8 instead of SO/UTF-8. > > There are three reasons: That's an interesting thought. Do you have a patch and, if so, did you try it? Does it, for instance, help for the issue reported in the thread starting at http://cygwin.com/ml/cygwin/2009-05/msg00245.html? After examining the issue Lenik reported in the above thread, I'm at a loss how to solve this problem in a generic way. The problem is that the filename changes dependent on the character set used in $LANG. The reason is that every time a multibyte filename has to be generated, it has to be converted from UTF-16 to multibyte. For instance, taking one of the filename from Lenik's example. It's stored on the filesystem as the UTF-16 sequence \u684c \u9762. If I set LANG to en_US.UTF-8, a readdir(2) call returns the multibyte sequence 0xe6 0xa1 0x8c 0xe9 0x9d 0xa2 If I set LANG to en_US.GBK, `ls' returns the filename 0xd7 0xc0 0xc3 0xe6 And in case LANG=C, `ls' returns 0x0e 0xe6 0xa1 0x8c 0x0e 0xe9 0x9d 0xa2 So, dependent on the character set setting in the application, the idea of the filename differs. That's not exactly helpful for interoperability between different applications. I can think of two potential solutions to fix this problem: (1) Always return filenames in UTF-8 encoding and pretend that UTF-8 is the way files are stored on disk. That results in unchangable filenames which are always valid. But what if an application sets LANG=".SJIS" and tries to create a file using SJIS character encoding? Should the file be created using the SJIS->UTF-16 conversion or should open fail with EILSEQ? That's not good. Why would it have to interpreted as all? Aren't filenames just opaque strings - with exceptions, say, for / and NUL to UNIX kernels? (2) If none of $LC_ALL/$LC_CTYPE/$LANG is set in the environment, then Cygwin uses the LC_CTYPE setting which corresponds to the current codepage. If one of $LC_ALL/$LC_CTYPE/$LANG is set in the environment, Cygwin uses that to convert pathnames. If the application uses setlocale, Cygwin uses that setting to convert pathnames. One problem can't be solved this way: If an application fetches and stores a filename, then switches the locale, and then tries to use the filename in another system call, the filename is potentially broken. Any better ideas? Just questions to kindle some brainstorming: - why do you need to touch the filename at all? I haven't read all of it. Is the UTF-16 on disk and we need to work around UTF-16 being intractable as C string? - some applications in the GNOME ballpark, for instance Gnumerica, do something like "treat as Unicode" and fall back to SOME_ENVIRONMENT_VARIABLE specified encoding (perhaps as a colon-separated list - not sure) - adding to my interspersed comment above: isn't the issue more about *presentation* of filenames to the user than internal workings? To me the main issue appears to be that filenames should look alike in a Cygwin application and in a native Windows application. I'd assume that applications can get really confused if you change file names behind their back. - if you speak of UTF-8, do you want to normalize file names? (I'd think you do.) Which normalization form will you choose? NFC (canonical) or NFD (compatibility)? -- Matthias Andree -- 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: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
Am 13.05.2009, 17:17 Uhr, schrieb Corinna Vinschen : I followed the suggestion to use UTF-8 for internal conversions when the locale is set to "C". This will also be used as default conversion when converting the Windows environment from UTF-16 to multibyte, unless the environment contains a valid LC_ALL/LC_CTYPE/LANG setting. The current working directory was also potentially unusable, if an application switched the locale. Now the CWD is re-evaluated after a setlocale call. Is Unicode normalization an issue here? -- Matthias Andree -- 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: Building "trueprint" fails with missing ref to _libintl_gettext
Am 01.06.2009, 22:48 Uhr, schrieb David Karr : -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of David Karr Sent: Monday, June 01, 2009 1:26 PM To: cygwin@cygwin.com Subject: Building "trueprint" fails with missing ref to _libintl_gettext I'm trying to build the "trueprint" app on Cygwin, and it's failing with the following: undefined reference to `_libintl_gettext' I had to do this many years ago, and I believe I ran into this then also, but I don't remember what I had to do to resolve it. When I run "configure" it comes out with a line (among others): checking for gettext... (cached) no I don't know if I'm simply missing a Cygwin package, or whether I have to hack the trueprint build to get it to work. The "gettext" package in Cygwin is installed. Never mind. I figured it out. I just added -lintl to the LIBS variable in the resulting src/Makefile. You can also do something like ./configure LIBS=-lintl or ./configure LIBS="-lintl -lfoobar" If configure was built with a semi-recent autoconf, that will also propagate into the Makefile without your needing to tweak the Makefile. HTH -- Matthias Andree -- 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: Unable to convert postscript to usable form, using either ps2pdf or gs
Am 01.06.2009, 23:33 Uhr, schrieb David Karr : I have a generated postscript file (from trueprint) that I need to get into a usable form on Windows, so I can view it and print it. I've tried both "ps2pdf" and "gs", with no success so far. I first tried using "ps2pdf". This fails with: --- % ps2pdf tp.ps tp.pdf GPL Ghostscript 8.62: Could not open temporary file /c/DOCUME~1/User/LOCALS~1/Temp/gs_dwvfJL Unable to open the initial device, quitting. --- It isn't an obvious permissions problem, because I can "touch" that file with no problem. Confirm - with for instance "type -a ps2pdf" or "which ps2pdf" if you're really invoking the ps2pdf you believe you're invoking, and if not, fix your installation and/or the PATH variable (though Windows's dialogue). I've had all sorts of issues when my Cygwin box inadvertently ended up using the notoriously-outdated ps2pdf that got installed by MATLAB and ended up earlier in the $PATH... I then tried just "gs tp.ps", and that fails with this: -- % gs tp.ps GPL Ghostscript 8.62 (2008-02-29) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusMonL-Regu font from /usr/share/ghostscript/fonts/n022003l.pfb... 2449904 1067520 4774456 3452340 ... 3456751 1 done. GPL Ghostscript 8.62: Could not open the file . Error: /invalidfileaccess in --showpage-- Operand stack: 1 true Is the output file in use? You cannot overwrite open file because most (not all) applications lock their input files. A notable exception for PDF viewers is SumatraPDF. -- Matthias Andree -- 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: ioctl(sock, SIOCGIFHWADDR, &ifr) fails with 1.7
Am 15.06.2009, 11:22 Uhr, schrieb Frédéric Bron :
To fix your application, call either
 struct ifconf ifc;
 ifc.ifc_len = sizeof (struct ifreq) * 32;
 ifc.ifc_buf = malloc (ifc.ifc_len);
 if (ioctl (fd, SIOCGIFCONF, &ifc))
  /* Resize ifc_buf and retry */
 else
  {
   struct ifreq *ifr = ifc.ifc_req;
   struct ifreq ifr2;
   for (int i = 0; i < ifc.ifc_len; i += sizeof (struct ifreq), ++ifr)
    if (!ioctl (fd, SIOCGIFADDR, &ifr2))
     /* Print result for that interface */
  }
Thanks, this works half! No need of ifr2, ifr is enough.
I saw the name change: 1.5 gives eth0, eth1, eth2, lo and 1.7 gives
{821C54BE-...}...
Careful - this isn't portable to newer BSDs, as there ifc_len may exceed
sizeof(struct ifreq).
getifaddrs() is probably the more portable solution here.
--
Matthias Andree
--
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: How to avoid having shell scripts which fail from killing Emacs shell?
David Karr schrieb:
>> -Original Message-
>> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf
>> Of Ken Brown
>> Sent: Monday, June 22, 2009 12:54 PM
>> To: cygwin@cygwin.com
>> Subject: Re: How to avoid having shell scripts which fail from killing
>> Emacs shell?
>>
>> On 6/22/2009 3:38 PM, David Karr wrote:
-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
>> Behalf
Of Ken Brown
Sent: Monday, June 22, 2009 12:26 PM
On 6/22/2009 10:53 AM, David Karr wrote:
> I've often been annoyed by shell scripts which fail for particular
> reasons, at which point it causes my Emacs shell buffer to get killed,
> with "Process shell<2> finished".
I don't recall ever seeing this happen, but maybe I just don't
>> remember.
Can you give me a simple test case?
>>> I'm not sure how complicated it needs to be. My test case gathers a
>> couple
>>> of parameters and then calls a Java (JDK 1.6.0_14) class. The class
>> throws
>>> an exception (file not found) in my test case (because I'm deliberately
>>> giving it parameters that will cause that). If I give it parameters
>> that
>>> will avoid the exception, then it doesn't kill the shell.
>>>
>>> Is that enough information to build a test case with?
>> No. I don't have JDK installed, and I don't have any idea how it
>> interacts with cygwin processes. If you can trigger the problem with a
>> simple shell script that doesn't require JDK, I'll see if I can help.
>> Or maybe someone on the list who does have JDK can suggest something for
>> you to try.
>
> I was able to produce an additional clue by writing a custom class for
> testing this.
>
> I found that the key is whether the Java class reads from stdin or not. I
> built a first version that takes a filepath on the command line, and whether
> I get the class to throw an exception or not, it exits the script without
> killing the shell. However, when I changed the class to also read a line of
> input from stdin, whether the filepath on the command line exists or not
> (i.e., whether the class throws an exception or not), it kills the shell at
> completion of the script.
>
> So, it has something to do with whether the sub-shell reads stdin or not. I
> have no idea what that indicates, but I'm sure that must be useful
> information.
Just a few pointers:
Does the problem go away if the java command is enclosed in parentheses, so as
to run it in a sub-shell?
Are you using (perhaps in the emacs configuration somewhere) shell options like
"-e" for the /outer/ shell?
Are you sourcing (". scriptname") rather than executing ("scriptname") your
scripts?
HTH
--
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 avoid having shell scripts which fail from killing Emacs shell?
Am 23.06.2009, 17:03 Uhr, schrieb David Karr : I just tried changing my script to instead just do a "read" with a prompt. This does not kill the shell at the end of the script. When I do it in Java, it kills the shell at the end of the script. Weird. Is Java trying anything WRT signalling process groups rather than just itself in the belief it were a session leader, i. e. when it tries to shoot its threads, it accidentally also shoots down the shell? Open stdin descriptors can hamper "detaching" processes. Does the Java stuff you're doing need stdin? If not, try running the JVM with input redirection such as <&- (closes stdin, assuming bash or similar) or -- Matthias Andree -- 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: /dev/ttyUSB0: No such file or directory
Leonid Krashenko schrieb: > Hello. > > I am new to the Cygwin and have a problem connecting a device with serial > output to the computer throw USB adapter. In Linux it's name is > /dev/ttyUSB0. I have no /dev/ttyUSB0 device in /dev (but ttyS0 works). > > So I plug the USB cable in, then trying to: > > $ cat /dev/ttyUSB0 > cat: /dev/ttyUSB0: No such file or directory Nevermind the name difference. Look up the proper COM name in device manager, and use /dev/com7 (adjust the number as needed). Note that Cygwin 1.5 only maps 16 serial devices (this is a problem for me as the crappy Toshiba Bluetooth software assigns a gazillion of Bluetooth COM ports it never needs and I never configured...), in doubt just remove an unused one (preferably one with a low number) in device manager and unplug and re-plug your USB to serial converter, Windows should then assign the lowest untaken number automatically. -- 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: ls and wildcards
Am 14.07.2009, 17:47 Uhr, schrieb Christopher Faylor : Btw, some versions of cmd.exe don't work well with executables which lack extensions. I just ran into this problem recently. I don't remember exactly where, probably it was with NT 4. Perhaps Cygwin 1.7 should do away with NT compatibility and require Win2k. While NT is much closer to the pack than the DOS 7 video game that Win 9X/ME used to be, NT4 has been out of extended support for five years now. While Cygwin certainly doesn't want to bully people into upgrading their costly M$ installations, I think it's useful to do that if it saves work the Cygwin maintainers. -- Matthias Andree -- 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: Cannot get 'Hello World' to compile
ken j schrieb:
> Hi, I am a COMPLETE newby at programming but am trying hard to get as far as
> I can on my own. I have installed Cygwin, with the gcc compiler package, and
> it all seems to be working OK. I'm using the 'Hello World' sample program
> used in the tutorial at cplusplus.com - code is as follows:
>
> // my first program in C++
>
> #include
> using namespace std;
>
> int main ()
> {
> cout << "Hello World!";
> return 0;
> }
>
> I have saved the text to file c:\cygwin\hello.c, then from within Cygwin I
> have typed:
> gcc /hello.c -o hello.exe. I get the following error messages:
Cygwin specific:
Install the gcc-g++ package (if you have multiple choices for gcc, install the
same version as the core compiler) and the corresponding libstdc++6 and
libstdc++6-devel packages.
(unless you've already done that - try cygcheck -c -d).
Generic GCC usage:
To compile C++ executables, use g++ to compile (not gcc) so that the front-end
looks for the proper headers and libraries. It is also advisable to call the C++
source files .cc or .cxx rather than .c (using .c makes the front-end believe
you want to compile C, not C++).
HTH
MA
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin 1.7/1.5 C99 conformance (GCC, libc)
Greetings, I recently figured that ctrio (from sourceforge.net) fails to link (GCC 3.4.4 here). Reason is that ctrio checks the __STDC_VERSION__ for C99 support, which there is, and assumes that the implementation were a hosted one (as opposed to a freestanding one) and uses powl() without further checks. Now, Cygwin 1.5 and 1.7 appear to lack long double library support in libc/libm -- which is required for a hosted C99 implementation however, but not for a freestanding C99 implementation. Trying to solve this, I found another Cygwin issue: GCC 3.4.4 sets __STDC_HOSTED__ to 1 by default (that's a GCC factory default). I propose that this gets overridden to 0 in Cygwin-ported GCC compilers until the library support for a C99-conforming full hosted implementation is in place, so that applications can safely check #if __STDC_HOSTED__ - 0 > 0 /* assume hosted C99 implementation, i. e. with powl() capable libc/libm */ /* ... */ #endif Thanks. Best regards -- Matthias Andree -- 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: Is this a known problem with getenv() ?
John Emmas schrieb:
> - Original Message -
> From: "John Emmas"
>>
>> I might just try experimenting with a very simple program and see if I
>> still get the error
>>
> I partially tracked down the problem, although I don't quite know how to
> solve it. If I write this simple console app:-
>
> #include
> #include
>
> int main ()
> {
>printf ( getenv ("PATH") );
>return 0;
> }
Gee, that is INSECURE. Insert some % in PATH for major fun including crashes
(anyone mistyping CMD.COM like variable expansions for instance, for instance
%USERPROFILE%)
For the records, the right way to do it is either:
puts(getenv("PATH"));
or
printf("%s\n", getenv("PATH"));
I've seen commercial Windows Explorer extensions (SECURITY software incidentally
that shipped with my laptop) kill my Explorer from such beginner's mistakes, and
it's a pity such bogus code is in publicly visible archives and needs to be
corrected through messages like mine.
> it outputs the correct path. However, if I create a GUI app and launch it
> under 'X', the path seems to change and includes lots of duplicated folders.
Probably one of the start scripts adds lots of entries, and X...
> I figured out that startxwin.bat is adding a few duplicated entries to my
> path but that doesn't explain why there are so many duplications and I don't
> know where the others might be coming from. However, I don't get any
> duplicates at all if I run XWin directly, instead of starting it with
> startxwin.bat.
...isn't the sole candidates. Check the manuals of involved shells for which
files they read at startup, under which conditions, and how. .bashrc, .profile
and corresponding files under /etc are prime candidates.
This isn't Cygwin or Cygwin/X specific though, but general Unix behaviour.
Cheers
--
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: Encoding of German 'umlauts' - please explain
Ronald Fischer schrieb:
> Maybe someone could enlighten me about the following:
>
> On Cygwin bash I see
>
> $ echo ü | od -cx
> 000 374 \n
> 0afc
> 002
>
> That means, the German letter ü has encoding 0xFC. If I do the same on CMD
> shell
> (the 'od' used here comes from the Gnu Utilities for Windows), I see:
>
> echo ü | od -cx
> 000 201 \r \n
> 2081 0a0d
> 004
>
> That is, ü is encoded as 0x81. Why is this different?
Because the code pages differ. 0xFC is ISO-8859-1 ("Latin 1") or -15 ("Latin 9")
or CP1252/Windows-1252 (Latin 1 Extended; the latter allocates 0x80...0x9f
differently than ISO-8859-1) and CMD uses CP437 or CP850.
--
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
1.5 unused error_start logic causes segfaults?
Greetings,
the following programs will segfault on Cygwin 1.5 with GCC 3.4.4 and GCC
4.3.2 UNLESS I define error_start program in $CYGWIN to contain
error_start=C:\cygwin\bin\dumper.exe. If error_start is defined, the
programs will abort as expected. With CYGWIN unset, the programs segfault.
The first will abort() properly on Cygwin 1.7/GCC 4.3.4 regardless of
whether error_start is defined or not.
What has dumper or error_start got to do with crashes under Cygwin 1.5?
Particularly, why does using dumper.exe "fix" the signal that the program
receives when it doesn't catch the exception?
Any hopes of this getting fixed in Cygwin 1.5? Programs below.
Program 1 (C++):
// try-except.cc
// compile: g++-4 -Wall -W -O -o try-except try-except.cc
// or: g++ -Wall -W -O -o try-except try-except.cc
int main() { throw("bad things happen"); }
Program 2 (C):
// try-abort.c
// compile: gcc-4 -Wall -W -O -o try-abort try-abort.c
// or: gcc -Wall -W -O -o try-abort try-abort.c
#include
int main(void) { abort(); }
Now note the "Segmentation fault" vs. "Aborted" below:
$ unset CYGWIN
$ ./try-except.exe
Segmentation fault (core dumped)
$ ./try-abort.exe
Segmentation fault (core dumped)
$ export CYGWIN='error_start=c:\cygwin\bin\dumper.exe'
$ ./try-except.exe
*** starting debugger for pid 2680, tid 1464
*** continuing pid 2680 from debugger call (1)
Aborted (core dumped)
$ ./try-abort.exe
*** starting debugger for pid 2900, tid 5796
*** continuing pid 2900 from debugger call (1)
Aborted (core dumped)
Oh, and let's try to set error_start to something that isn't an executable
program:
$ export CYGWIN='error_start=C:\'
$ ./try-except.exe
terminate called after throwing an instance of 'char const*'
*** starting debugger for pid 5688, tid 3752
7 [sig] try-except 5112 try_to_debug: Failed to start debugger,
Win32 error 3
*** continuing pid 5688 from debugger call (0)
Segmentation fault (core dumped)
Might the error_start logic be broken on Cygwin 1.5, meaning that any
signal causing program termination runs bad code in the Cygwin DLL? This
bad code appears to cause a segfault instead of the original signal unless
a debugger can properly attach.
$ uname -r
1.5.25(0.156/4/2)
On Windows XP Version 2002 Tablet PC Edition 2005 Service Pack 3.
--
Matthias Andree
--
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: write() to /dev/ttyS0 has no effect
Børge Strand-Bergesen schrieb:
> I'm writing some C code to control an external MCU over UART.
> Everything works like a charm using TeraTerm or cat >>/dev/ttyS0. gcc
> is 3.4.4. In a different program (not inserted), I am able to use
> read() to get information from the MCU. Cygwin is "CYGWIN_NT-5.1
> 1.5.25(0.156/4/2) 2008-06-12 19:34".
>
> However, it seems like no information is sent when I call write(). Are
> there any known bugs with Cygwin when it comes to this?
"Works for me", albeit with MSP430 behind a FTDI USB/serial converter and
without CRTSCTS and lower bit rate (57600).
> I have inserted my code below. Thanks for any help!
>
> "f" is a valid command to the MCU. The MCU will disregard any \r or
> \n. I have tried hitting the enter button, not just 'a' on the
> keyboard.
>
>
> Borge
>
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define BAUDRATE B115200
> #define MODEMDEVICE "/dev/ttyS0"
> #define _POSIX_SOURCE 1 /* POSIX compliant source */
This must be before the first #include.
> #define FALSE 0
> #define TRUE 1
>
>
> FILE *keyboard;
> int status;
>
> main()
> {
> int fd,c, res;
> struct termios oldtio,newtio;
>
> keyboard = fopen("/dev/tty", "r"); //open the terminal keyboard
What's that good for? You're not using that.
> if (!keyboard)
> {
> fprintf(stderr, "Unable to open /dev/tty\n");
> exit(1);
> }
>
> fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY );
> if (fd <0) {perror(MODEMDEVICE); exit(-1); }
>
> fcntl(fd, F_SETFL, 0); // Needed???
Not needed.
>
> tcgetattr(fd,&oldtio); // Save current
> port settings
>
> // Non-canonical init.
> bzero(&newtio, sizeof(newtio));
bzero() isn't standard. Use memset(), sample below.
> newtio.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD;
Does the µC support CRTSCTS? If not, that's why it fails.
Also, BAUDRATE may not fit into speed_t according to /usr/include/sys/termios.h,
so you're losing the "extended baud rate" flag and are actually programming 75
Baud instead of 115200. Use cfsetXspeed (X is i or o) to manipulate newtio
instead, example (in C++):
struct termios newtio;
/* configure serial interface to 57600 8N1 no-canonical */
memset(&newtio, 0, sizeof(newtio));
newtio.c_cflag = CS8 | CLOCAL | CREAD;
newtio.c_iflag = 0;
newtio.c_oflag = 0;
newtio.c_lflag = 0;
newtio.c_cc[VTIME] = 0;
newtio.c_cc[VMIN] = 1; /* at least 1 characters */
if (cfsetispeed(&newtio, B57600)) throw("cfsetispeed");
if (cfsetospeed(&newtio, B57600)) throw("cfsetospeed");
if (tcflush(fd, TCIFLUSH)) throw("tcflush");
if (tcsetattr(fd, TCSANOW, &newtio)) throw("tcsetattr");
> newtio.c_iflag = IGNPAR;
> newtio.c_oflag = 0;
> newtio.c_lflag = 0;
> newtio.c_cc[VTIME] = 0; //
> inter-character timer unused
> newtio.c_cc[VMIN] = 5; // blocking
> read until 5 chars received
>
> tcflush(fd, TCIFLUSH);
> tcsetattr(fd,TCSANOW,&newtio);
>
> while (1)
> {
> status = getc(stdin);
> if (status == 'a') {
> char outbuf[] = "f";
> printf("%s", outbuf); // This
> printout is ok
> write(fd, outbuf, 1); // This doesn't
> seem to get sent down the uart!
> }
>
> }
You're apparently not reading from the serial line. Is that intentional?
> tcsetattr(fd,TCSANOW,&oldtio); // Restore port settings
This is unreached (dead) code.
> }
HTH
--
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: Editing protected files in Windows 7 (like the etc/hosts file)
Am 16.05.2011 11:09, schrieb Avishai Geller: > How do I edit my hosts file in cygwin on Windows 7? VI opens it in read-only > mode. I have administrator permissions, but Windows 7 has that UAC feature > which I think is preventing editing the file. Don't second-guess. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash: cygpath: command not found
Am 16.06.2011 04:03, schrieb jairo supelano: > Hi, i require to use cygpath, and this is supposed to come with standard > installation. i get this message, first i tried default installation, tough i > may have changed install defaults in the first try (i dont remember if i > changed > them in the first try), but if i did, it was to add new packgages (bitmap > libs, Please, next time, use paragraphs (blank lines) to split your text into smaller and more readable chunks of relevant information. If necessary, set your mailer to not send enriched or HTML text, but just plain text. Thank you. -- 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
rebaseall failure/perlrebase conflict?
Trying to run rebase fails for me. It rebases a truckload full of dlls, then: /usr/lib/parrot/2.3.0/dynext/rational.dll: new base = 5f64, new size = 2 /usr/lib/parrot/2.3.0/dynext/subproxy.dll: new base = 5f62, new size = 2 ReBaseImage (/usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Image/Magick/Magick.dll) failed with last error = 6 And sure enough, no write permission on the file (I had previously run) $ ls -l /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Image/Magick/Magick.dll -r-xr-xr-x 1 mandree root 284686 2010-05-03 16:14 /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Image/Magick/Magick.dll #1 why would rebaseall fail here? perlrebase succeeds, and peflags either doesn't touch this, or doesn't fail either. #2 I'm a bit worried that I am the owner rather than "Administrator", I guess this is an artifact of the Win7 UAC. I had started a CMD.EXE as administrator and launched ash there. $ uname -a CYGWIN_NT-6.1 COMPUTER 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin (The whole story started when - again - after an upgrade "git svn rebase" would fail loading Perl DLLs to the same address. This is a nuisance.) -- Matthias Andree -- 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: Q: rebaseall/rebaseperl ?
Am 05.07.2010, 23:09 Uhr, schrieb Cyrille Lefevre: Hi, any reasons why rebaseall and rebase perl aren't executed at compile time ? or at packaging time ? Probably because it's not possible to oversee which installation would need which libraries later, and because you'd have to have a registry, or algorithm to derive base addresses, for each and every potential library. Meaning: not manageable with reasonable effort. -- Matthias Andree -- 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: Interesting discovery in the C library that Cygwin uses
Am 09.07.2010, 01:34 Uhr, schrieb Gregg Levine: (warnings about char subscripts) Basically the program supporter there wants the people here for Cygwin to, ah, fix their C library. I'm not convinced that's necessary, but which C library is used here? And what could be fixed? The C library (newlib) is fine, it is actually helpful here by emitting warnings for actual program defects. The supporter should be sold a clue, in the form of a copy of IEEE Standard 1003.1 or a deep link to the opengroup.org website. The urjtag source however should be fixed. It abuses the ctype.h interfaces. Arguments to the tolower() and other to*() and isspace() and other is*() functions MUST be cast to unsigned char (unless they are already unsigned char). Background is that these functions need to support the usual 8bit character range plus the 257th "character" EOF (-1). So the is*() functions will have to use a wider type than char, and now sign extension matters. If you don't cast the input to unsigned char, an argument of 0xff will alias EOF although it is not the same, and 0x80...0xfe will lead to undefined behaviour, possibly even crashes. Note: the warning may be specific to Cygwin, but the underlying program will show on more systems with input outside ASCII. I recall that at least some versions of Solaris would misbehave if you passed non-ASCII characters (think umlauts or accented characters, or Asian/Cyrillic/other national scripts) to these ctype.h functions. There are probably more... -- Matthias Andree -- 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 extremely slow after updating from 1.5.1 to 1.7.5
Am 12.07.2010 03:00, schrieb Jet Thompson: > It is now taking over 30 seconds for bash to come up, > whereas in 1.5 it would take 1-2 seconds. > > Doing an ls of my ~ directory takes 5 seconds. > > Running a cucumber test takes 5-6 minutes. > > Any idea what could be causing this? Virus, Spyware and similar scanners, and broken software. > At this point, I can not use Cygwin for development. > Not feasible to use such a slow environment. > > Hope someone may have some good ideas. > I am using an older XP machine, but still it is > dual 2.8 Xeon processors, 800MHz bus, 7200rpm > sata hard drive with 8MB cache. It is painful > to see such dismal performance. ls isn't representative, as it uses stat() which is painfully slow on Cygwin. If bash is slow to start, see if uninstalling bash-completion fixes it. For me it helped quite a bit. -- Matthias Andree -- 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 select() on console
Am 15.07.2010, 07:49 Uhr, schrieb Christopher Faylor: On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote: When select() is used to test for input availability on the standard cygwin console in normal (cooked) mode, it indicates input is available as soon as any key is pressed. However, a call to read(0,...) will (correctly) block until a terminating RETURN is entered. select() should only indicate input is available when a call to read would *not* block - ie when a read call will immediately return at least one character or an error such as EOF. The behaviour of the following test case illustrates this. When run in a console window typing a single key causes the program to wait for the whole line. When run under mintty or on Linux the select() calls will continue to return no input until RETURN is entered. Since, AFAIK, Windows has no way to do this, I don't see how it could be done easily. You could, I guess, pull characters into a buffer until a newline was found but that would be pretty error-prone and any use of select() would potentially invalidate console i/o for subprocesses. So, I don't see this changing anytime soon. Is there a way to detect that the application is run from a Windows console rather than mintty? If so, cygwin1.dll could print a warning to the console, (something along the lines that running the application under some X11 terminal or mintty is advised) and return EINVAL, or abort the application, in either case if POSIXLY_CORRECT is set in the environment, much like some GNU tools will switch to a more POSIX compliant behaviour with that variable. Just a rough thought... -- Matthias Andree -- 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: configure error: cannot find install-sh or install.sh in ../.. "../../winsup/cygwin"/../..
Am 19.07.2010 17:29, schrieb Ryan McLeod: > I get the above error when I am trying to cross-compile openswan for > cygwin as laid out here: > http://www.cygwin.com/ml/cygwin/2005-08/msg00175.html > > The only thing i do differently is: > > ../../winsup/configure --prefix=/myprefix/cross > --target=i686-pc-cygwin --without-headers \ > > --with-newlib --disable-shared --enable-languages=c,c++ > > changes to: > > ../winsup/configure --prefix=/myprefix/xelerance/cross/win2k > --target=i686-pc-cygwin --without-headers \ > > --with-newlib --disable-shared --enable-languages=c,c++ > > The prefix change is mentioned as that in the openswan documents, but > considering i only go up one directory from winsup > > and into a build directory from there, not sure why he specified > ../../winsup. I did have to copy install-sh, config.guess and > config.sub into the winsup directory, as i was getting configure > errors then with the install-sh. But now its asking for it > > in a directory that seems to be irrelevant to the install. configure > error: cannot find install-sh or install.sh > in ../.. "../../winsup/cygwin"/../.. > > Thanks for any assistance. Without looking at the actual issue (no time), and just as a pointer to a solution: If autoconf/automake are involved, there are pre-defined variables such as $(srcdir), $(top_srcdir) and similar that could replace hard-coded prefixes such as "../..". Details: Please see the "Preset Output Variables" section in the autoconf manual. -- Matthias Andree -- 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: cron starts multiple commands
Am 20.07.2010, 19:15 Uhr, schrieb matias kaukonen: I'm using cron to backup my files. The problem is cron seems to repeat the backup every minute for 5 minutes. Pls refer to my cron file. -- SHELL=/bin/bash PATH=/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/lhovey/utils/scripts/:/home/lhovey/backups/:. time_stamp=$(date +%y.%m.%d-%H) @daily ./backups/make_backup.bash - Has anyone seen this before with cygwin? Do they know what the fix is for this? Does the cron service crash and get restarted by your service configuration? Check your system event log, or the output of cronevents for hints. Does the make_backup script succeed and complete, or does it abort prematurely? -- Matthias Andree -- 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: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
Am 10.08.2010, 19:54 Uhr, schrieb Christopher Faylor: I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like "c:\foo" in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. How about pointing people to mingw-make? I've been using that to build ntemacs for quite a while... -- Matthias Andree -- 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: [ANNOUNCEMENT] Update on status of make-3.82 release for cygwin
Am 10.08.2010, 23:00 Uhr, schrieb Christopher Faylor: On Tue, Aug 10, 2010 at 10:51:38PM +0200, Matthias Andree wrote: Am 10.08.2010, 19:54 Uhr, schrieb Christopher Faylor: I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like "c:\foo" in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. How about pointing people to mingw-make? I've been using that to build ntemacs for quite a while... http://cygwin.com/ml/cygwin-announce/2008-02/msg6.html Exactly - that why I'm asking why this win32/ms-dos file name re-enable thingy comes up again for Cygwin's GNU make... -- Matthias Andree -- 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: Postinstall script errors
Am 12.08.2010 15:37, schrieb Jeremy Ramer: > On Thu, Aug 12, 2010 at 3:59 AM, Corinna Vinschen > wrote: >> On Aug 11 09:18, Jeremy Ramer wrote: >>> I recently upgraded from cygwin 1.5 to 1.7. At the end of the install >>> there were errors with some of the postinstall scripts. From the >>> setup.full.log: >>> >>> 2010/08/11 08:39:53 running: C:\cygwin\bin\bash.exe --norc --noprofile >>> /etc/postinstall/bash.sh >>> ln: creating symbolic link `/dev/stdin': File exists >>> 2010/08/11 08:39:54 abnormal exit: exit code=1 >>> 2010/08/11 08:39:54 running: C:\cygwin\bin\bash.exe --norc --noprofile >>> /etc/postinstall/passwd-grp.sh >>> 2010/08/11 08:39:55 abnormal exit: exit code=1 >>> >>> >>> I tried manually running the scripts with mixed results >>> >>> $ bash --norc --noprofile /etc/postinstall/bash.sh ; echo $? >>> 0 >>> >>> $ bash --norc --noprofile /etc/postinstall/passwd-grp.sh ; echo $? >>> 1 >>> >>> I tired manually running the commands inside passwd-grp.sh and they >>> all return 0. So I'm not sure what exactly is failing. Is there >>> anything I should do to investigate? >> >> That's probably a fault in the postinstall scripts. It would be nice if >> you could provide more details about what fails exactly in the script, >> or better, what in the script has a non-0 exit code. That would help us >> lazy maintainers to fix the scripts faster. > > The issue with the passwd-grp.sh script seems to be the last two lines. > > [ "$created_passwd" = "yes" ] && /bin/chgrp --silent root /etc/passwd > [ "$created_group" = "yes" ] && /bin/chgrp --silent root /etc/group > > I verified that $created_passwd and $created_group were both no so > both conditionals will fail. But because the last conditional is the > last thing run, the script returns 1. Adding an exit 0 to the script > fixes it, but I'm not sure if that accomplishes what you want from the > script. PLEASE DON'T. Adding an "exit 0" will mask the error and just reinstate the former state of silently failing postinstall scripts more rigidly. This is not desirable. The proper way to fix this is: set -e # this is providing that the whole script is written properly. # it causes immediate exit after one command (outside if, and # outside || or && lists) fails - usually desirable, but takes more # work because you can't write the scripts as sloppily as the # snippet you've just shown from passwd-grp.sh. # # ...other work... # if [ "$created_passwd" = "yes" ] ; then /bin/chgrp --silent root /etc/passwd fi if [ "$created_group" = "yes" ] ; then /bin/chgrp --silent root /etc/group fi -- Matthias Andree -- 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: Postinstall script errors
Am 12.08.2010 16:40, schrieb Corinna Vinschen: > On Aug 12 16:10, Matthias Andree wrote: >> Am 12.08.2010 15:37, schrieb Jeremy Ramer: >> > I verified that $created_passwd and $created_group were both no so >> > both conditionals will fail. But because the last conditional is the >> > last thing run, the script returns 1. Adding an exit 0 to the script >> > fixes it, but I'm not sure if that accomplishes what you want from the >> > script. >> >> PLEASE DON'T. >> >> Adding an "exit 0" will mask the error and just reinstate the former state of >> silently failing postinstall scripts more rigidly. This is not desirable. The >> proper way to fix this is: >> >> set -e # this is providing that the whole script is written properly. >> # it causes immediate exit after one command (outside if, and >> # outside || or && lists) fails - usually desirable, but takes more >> # work because you can't write the scripts as sloppily as the >> # snippet you've just shown from passwd-grp.sh. >> # >> # ...other work... >> # >> if [ "$created_passwd" = "yes" ] ; then >> /bin/chgrp --silent root /etc/passwd >> fi >> >> if [ "$created_group" = "yes" ] ; then >> /bin/chgrp --silent root /etc/group >> fi > > I misinterpreted the `chgrp --silent'. I thought it would result > in an exit code of 0 from chgrp, but it just suppresses the error > messages. Sorry about that. And you're missing the other point that I've just explained on cygwin-apps@, see http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html "[ $blah = foo ] && ..." is usually suspicious and often triggers bogus failures or premature exit, depends on if running under set +e (default) or set -e (advised). -- Matthias Andree -- 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: Postinstall script errors
Am 12.08.2010 16:54, schrieb Corinna Vinschen: > On Aug 12 16:52, Matthias Andree wrote: >> Am 12.08.2010 16:40, schrieb Corinna Vinschen: >> > On Aug 12 16:10, Matthias Andree wrote: >> >> Am 12.08.2010 15:37, schrieb Jeremy Ramer: >> >> > I verified that $created_passwd and $created_group were both no so >> >> > both conditionals will fail. But because the last conditional is the >> >> > last thing run, the script returns 1. Adding an exit 0 to the script >> >> > fixes it, but I'm not sure if that accomplishes what you want from the >> >> > script. >> >> >> >> PLEASE DON'T. >> >> >> >> Adding an "exit 0" will mask the error and just reinstate the former >> >> state of >> >> silently failing postinstall scripts more rigidly. This is not desirable. >> >> The >> >> proper way to fix this is: >> >> >> >> set -e # this is providing that the whole script is written properly. >> >> # it causes immediate exit after one command (outside if, and >> >> # outside || or && lists) fails - usually desirable, but takes >> >> more >> >> # work because you can't write the scripts as sloppily as the >> >> # snippet you've just shown from passwd-grp.sh. >> >> # >> >> # ...other work... >> >> # >> >> if [ "$created_passwd" = "yes" ] ; then >> >> /bin/chgrp --silent root /etc/passwd >> >> fi >> >> >> >> if [ "$created_group" = "yes" ] ; then >> >> /bin/chgrp --silent root /etc/group >> >> fi >> > >> > I misinterpreted the `chgrp --silent'. I thought it would result >> > in an exit code of 0 from chgrp, but it just suppresses the error >> > messages. Sorry about that. >> >> And you're missing the other point that I've just explained on cygwin-apps@, >> see >> http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html > > No, I didn't. Sorry to be so unrelenting, but you are still missing the point. Please re-read Jeremy's analysis at <http://cygwin.com/ml/cygwin/2010-08/msg00285.html>. NOTE: *chgrp was not ever run* in the failing scenario, so whatever you pass as chgrp arguments, --silent or not, is irrelevant. What actually happened was: created_group=no ... [ "$created_group" = "yes" ] && # remainder short-circuited, failure stands And since this [ ] && line was the last in the script, the failure from the "[" (= test) command propagated through to the caller and finally through setup.exe which duly reported it. -- Matthias Andree -- 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: Postinstall script errors
Am 12.08.2010 17:15, schrieb Corinna Vinschen: > On Aug 12 17:04, Matthias Andree wrote: >> Am 12.08.2010 16:54, schrieb Corinna Vinschen: >> > On Aug 12 16:52, Matthias Andree wrote: >> >> Am 12.08.2010 16:40, schrieb Corinna Vinschen: >> >> > I misinterpreted the `chgrp --silent'. I thought it would result >> >> > in an exit code of 0 from chgrp, but it just suppresses the error >> >> > messages. Sorry about that. >> >> >> >> And you're missing the other point that I've just explained on >> >> cygwin-apps@, see >> >> http://www.cygwin.com/ml/cygwin-apps/2010-08/msg00116.html >> > >> > No, I didn't. >> >> Sorry to be so unrelenting, but you are still missing the point. > > No, I didn't. Think about it. And whatever I missed or not missed, > can we please stop a moot discussion? I thought about it and reviewed the messages, my opinion still stands, but I agree to quit a discussion that isn't proceeding to anywhere. -- Matthias Andree -- 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/Where do I get an older version of Cygwin?
Am 26.08.2010 21:41, schrieb Blaine Miller: > Again, I agree. I'm between a rock and a hard place here. I have to > prove it's not the current version of Cygwin (also read *free*) and new > hardware (read *costs them some money*). > > I have related to you and others at Cygwin user list both of my issues > of cron possibly causing a system fault and can't kill the ssmtp > dead.letter running over. Does it have to be ssmtp? How about Exim? Works for me without exploding dead.letter files. You can have cron logging to syslog-ng, and suppress cron's sending mail from the crontab, if that helps. -- Matthias Andree -- 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: Building Mutt: configure: invalid value of canonical build
On 30.08.2010 23:52, Michael Ludwig wrote: The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. [... long whine about non-working build snipped ...] Did you use the ./prepare script first if building from Hg (Mercurial) rather than a tarball? If so, did you use setup.exe since to remove/upgrade autoconf, automake, or related packages? That might have invalidated symlinks. Also be sure not to mix MinGW and Cygwin utilities - this is a constant source of confusion. -- 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: Building Mutt: configure: invalid value of canonical build
Am 01.09.2010, 01:37 Uhr, schrieb Michael Ludwig: Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200): On 30.08.2010 23:52, Michael Ludwig wrote: >The mutt mail reader shipping with Cygwin does not have SMTP >enabled, which I'd like to give a try. So I tried to build mutt, >but encountered problems. [... long whine about non-working build snipped ...] Whatever pills you've taken to discern lengthiness and whininess, I'd definitely recommend you stop taking them, especially when driving or writing email. It's your problem if you don't like the answers. Your "fix" attempts break the build system further, meaning that: if you "touch config.sub", you create a blank canonicalization script, so don't complain about canonicalization errors or other malfunctions -- you triggered those that you caused yourself. You chose the blue pill, asking for blitheness, joy, and ignorance. So to sell you a faint clue of what the red pill might have provided if you had so chosen: a *real* config.sub is what should be doing the canonicalization -- a blank script won't achieve that. automake --add-missing (which is called as part of ./prepare) is what would install a set of real config.sub, install-sh, missing, and related scripts. The question of if the mutt distribution is incomplete is a distinct one - and the command line you showed on Monday works fine on a mutt HEAD checkout from the Mercurial repo. -- Matthias Andree -- 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: Building Mutt: configure: invalid value of canonical build
Am 01.09.2010, 01:37 Uhr, schrieb Michael Ludwig: Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200): On 30.08.2010 23:52, Michael Ludwig wrote: >The mutt mail reader shipping with Cygwin does not have SMTP >enabled, which I'd like to give a try. So I tried to build mutt, >but encountered problems. [... long whine about non-working build snipped ...] Whatever pills you've taken to discern lengthiness and whininess, I'd definitely recommend you stop taking them, especially when driving or writing email. Sorry, the first edition went out prematurely. Now for the good one: It's your problem if you don't like the answers. Your "fix" attempts break the build system further, meaning that: if you "touch config.sub", you create a blank canonicalization script, so don't complain about canonicalization errors or other malfunctions -- you triggered those yourself. You chose the blue pill, asking for blitheness, joy, and ignorance. So to sell you a faint clue of what the red pill might have provided if you had so chosen: a *real* config.sub is what should be doing the canonicalization -- a blank script won't achieve that. automake --add-missing (which is called as part of ./prepare) is what would install a set of real config.sub, install-sh, missing, and related scripts. The question of if the mutt distribution is incomplete is a distinct one - and the command line you showed on Monday works fine on a mutt HEAD checkout from the Mercurial repo if you follow Csaba's advice; however you can usually just omit --build=... and the auto* built stuff will call config.guess to figure. -- Matthias Andree -- 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.[67]: getting bash prompt takes > 50 seconds
Am 02.09.2010, 04:30 Uhr, schrieb Mark Callow: Hi Andrey, Did you tried to *uninstall* bash-completion? I have now. Surprisingly (to me) it worked. The time-to-prompt has dropped to ~5 seconds on one of the machines and ~8 seconds on the other. Both are still too long but a vast improvement over 50 seconds. You can open a cmd.exe terminal window and type "bash --login -x" (or -xv) to figure if it spends a particularly long time in a certain area of the .bashrc execution, however, Cygwin is indeed a lot slower than Unix when shell scripting, because creating Unix processes is very costly in Cygwin, and that is an operation that happens a lot in shell scripts... -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Looking for experienced CygWin Users
Am 06.10.2010 10:12, schrieb CygwinForums: > > We just started a Cygwin based forum in an attempt to build the Cygwin users > community support for newer users. We need some forum mods to assist in the > everyday tasks, as well as provide support for our users. Bad idea IMO. As though such fragmentation of support places solved any problem. Instead, the inconciseness of a forum will make matters harder and lead to even more repeated questions... -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Looking for experienced CygWin Users
Am 06.10.2010 13:05, schrieb CygwinForums: > > I designed our forum to help users that are *NEW* to Cygwin, more for > discussion of the programs uses and empowering users, rather that direct > support of issues. > > I am very open to ideas, as this project was designed to aid the community, > not distract it. Yeah, so scrap that forum stuff altogether and volunteer for writing Cygwin documentation, websites, etc. I'm sure (without checking) there's enough work waiting for contributors. -- Matthias Andree -- 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
rebaseall failures, propsal
Running rebase, I frequently get errors like this: ReBaseImage (/usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Image/Magick/Magick.dll) failed with last error = 6 ...even if it's right as it stands (see below), and even if I triggered it myself by running "perlrebase", this is a nuisance, because rebaseall aborts. Jason, could you possibly make sure that rebase (or rebaseall) makes all files to be rebased writeable? perlrebase does just that: cat rebase$suff.lst | xargs chmod u+w rebase -v -b $baseaddr -T rebase$suff.lst cat rebase$suff.lst | xargs chmod u-w ...which might work more or less the same for rebaseall. -- Matthias Andree -- 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: scp just spews usage
Am 24.11.2010 15:26, schrieb Benjamin Anderson: > Hi, > I've been using ssh with cygwin for years w/ no issues. After my last > upgrade, I am not able to use scp (ssh still works). > > $ scp myfile myusern...@myserver:~ > usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] >[-l limit] [-o ssh_option] [-P port] [-S program] >[[u...@]host1:]file1 ... [[u...@]host2:]file2 > > This same command has worked for me for long time. Any ideas what's > happening now? (I have tried rebooting since the upgrade). Does it work without trailing tilde (~)? SCP/SSH will put you into the home directory by default anyways, so it's not strictly required. Are there blanks in any of the names? Then remember to quote the command properly from the shell. Is scp an alias? Find out with "type alias" when using bash. -- Matthias Andree -- 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: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Am 02.12.2010 18:54, schrieb Jason Curl:
> Linux getifaddrs():
> * eth0 -> AF_INET
> * eth0 -> AF_INET6
>
> Cygwin getifaddrs():
> * {xxx} -> AF_INET6
> * {xxx}:1 -> AF_INET
>
> This is another reason why I think it could be architecturally simpler to just
> have multiple records and to drop the interface indices all together of the
> form
> ":1".
Is there anything that mandates Linux/Solaris behaviour? Else you might as well
argue with BSD which doesn't have these :N extensions.
--
Matthias Andree
--
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
1.7.7: rm -rf sometimes fails - race condition?
Greetings, I see that "rm -rf" on a directory sometimes fails, like here: |>>> Creating source package | fetchmail-6.3.19-1.cygport | fetchmail-6.3.19-1.cygwin.patch | fetchmail-6.3.19.tar.bz2 |>>> Removing work directory in 5 seconds... |>>> Removing work directory NOW. | rm: cannot remove `/usr/src/fetchmail-6.3.19-1/inst/usr/share/locale/da': Directory not empty | Command exited with non-zero status 1 Alternatively, you get "...in use" for an error, however, in this case, it appears that the corresponding syscall triggered by rm(1) had already returned but the file wasn't fully removed from the directory yet. I've seen this happen for a while now. This happens sporadically, and retrying the operation usually succeeds, so it matters less in an interactive shell. However, this often breaks scripts, in this case, cygport. This looks like either a premature return from a syscall or libcall, or like a genuine race in the system. In case it matters, this is - Windows 7 Prof. 32-bit German - with Sophos Endpoint Security and Control ver. 9 and - Microsoft Windows Defender. - coreutils 8.5-2 - uname -a: CYGWIN_NT-6.1 somehost 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Has anyone seen similar things? Is it worth investigating where Sophos hooks into the system with Helios or other tools? (Judging from the list traffic, Sophos is rather the invisible observer type than getting in the way like usual suspects among the BLODA residents do.) I'd rather not see the need to disable virus inspection software in order to run Cygwin though. Thanks & Best regards -- Matthias Andree -- 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.7: rm -rf sometimes fails - race condition?
Am 10.12.2010 19:26, schrieb Christopher Faylor: > On Fri, Dec 10, 2010 at 06:49:09PM +0100, Matthias Andree wrote: >>Greetings, >> >>I see that "rm -rf" on a directory sometimes fails, like here: >> >>|>>> Creating source package >>| fetchmail-6.3.19-1.cygport >>| fetchmail-6.3.19-1.cygwin.patch >>| fetchmail-6.3.19.tar.bz2 >>|>>> Removing work directory in 5 seconds... >>|>>> Removing work directory NOW. >>| rm: cannot remove `/usr/src/fetchmail-6.3.19-1/inst/usr/share/locale/da': >>Directory not empty >>| Command exited with non-zero status 1 >> >>Alternatively, you get "...in use" for an error, however, in this case, it >>appears that the corresponding syscall triggered by rm(1) had already returned >>but the file wasn't fully removed from the directory yet. >> >>I've seen this happen for a while now. This happens sporadically, and >>retrying >>the operation usually succeeds, so it matters less in an interactive shell. >>However, this often breaks scripts, in this case, cygport. >> >>This looks like either a premature return from a syscall or libcall, or like a >>genuine race in the system. >> >>In case it matters, this is >>- Windows 7 Prof. 32-bit German >>- with Sophos Endpoint Security and Control ver. 9 and >>- Microsoft Windows Defender. >>- coreutils 8.5-2 >>- uname -a: >> CYGWIN_NT-6.1 somehost 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin >> >> >>Has anyone seen similar things? > > Yes and you seem to have nailed the problem - it happens when a virus checker > hooks into a syscall and allows it to return before completion. I don't think > we want to modify Cygwin to not trust success return values from system calls. Well, I don't know a solution but I think this is unexpected behaviour. You can delete thousands of files and dirs without bad things happening, but once in a while it fails. What file of the many (cvsweb isn't really amenable to searches ;-)) implements unlink()? -- Matthias Andree -- 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.7: rm -rf sometimes fails - race condition?
Am 10.12.2010 19:26, schrieb Christopher Faylor: > On Fri, Dec 10, 2010 at 06:49:09PM +0100, Matthias Andree wrote: >>Greetings, >> >>I see that "rm -rf" on a directory sometimes fails, like here: >> >>|>>> Creating source package >>| fetchmail-6.3.19-1.cygport >>| fetchmail-6.3.19-1.cygwin.patch >>| fetchmail-6.3.19.tar.bz2 >>|>>> Removing work directory in 5 seconds... >>|>>> Removing work directory NOW. >>| rm: cannot remove `/usr/src/fetchmail-6.3.19-1/inst/usr/share/locale/da': >>Directory not empty >>| Command exited with non-zero status 1 >> >>Alternatively, you get "...in use" for an error, however, in this case, it >>appears that the corresponding syscall triggered by rm(1) had already returned >>but the file wasn't fully removed from the directory yet. >> >>I've seen this happen for a while now. This happens sporadically, and >>retrying >>the operation usually succeeds, so it matters less in an interactive shell. >>However, this often breaks scripts, in this case, cygport. >> >>This looks like either a premature return from a syscall or libcall, or like a >>genuine race in the system. >> >>In case it matters, this is >>- Windows 7 Prof. 32-bit German >>- with Sophos Endpoint Security and Control ver. 9 and >>- Microsoft Windows Defender. >>- coreutils 8.5-2 >>- uname -a: >> CYGWIN_NT-6.1 somehost 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin >> >> >>Has anyone seen similar things? > > Yes and you seem to have nailed the problem - it happens when a virus checker > hooks into a syscall and allows it to return before completion. I don't think > we want to modify Cygwin to not trust success return values from system calls. The interesting part is that it also happens with Sophos deinstalled and the Defender service stopped... so it's not apparently Sophos that causes this. -- Matthias Andree -- 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.7: rm -rf sometimes fails - race condition?
Am 10.12.2010 22:18, schrieb Warren Young: > On 12/10/2010 12:22 PM, Matthias Andree wrote: >>>> Has anyone seen similar things? >>> >>> Yes and you seem to have nailed the problem - it happens when a virus >>> checker >>> hooks into a syscall and allows it to return before completion. I don't >>> think >>> we want to modify Cygwin to not trust success return values from system >>> calls. >> >> Well, I don't know a solution but I think this is unexpected behaviour. > > When some bit of third-party software patches the kernel and breaks its > API -- which includes details like "when this call returns a success > code, it means it succeeded" -- that is going to result in unexpected > behavior in any program that calls that syscall. > > If you were to take a survey of existing Windows programs and sort them > according to density of calls into the deepest parts of the Windows > kernel, I'd bet Cygwin would be way over at the high-density end. Since > antimalware programs hook these same parts of the kernel to do their > job, bugs in those hooks will affect Cygwin more often than most other > Windows programs. > > Cygwin doesn't -- and shouldn't -- patch around such bugs. Cygwin > probably contains code to work around bugs in Windows itself, but that's > as far as it should go. > > You say you've disabled your antimalware software and the problem > persists. I doubt you've actually gotten yourself back to a stock > Windows configuration, but if so, you should be able to write a program > that will show the same behavior on anyone's system. If you can do > that, I think a fix would shortly follow. I'm not making promises of > other people's resources, just making a history-based prediction. Certainly I don't get back to a stock Windows configuration, and that's hardly what a typical Cygwin installation would look like anyways; however, the software that's failing is rm.exe in certain circumstances when running "cygport fetchmail-6.3.19-1 all", so it's not exactly rocket science I've been trying :) Is there any software other than Helios that would be recommended to list patched/hooked (non-Windows-/Microsoft) system calls? Perhaps I can find out what application or service might cause that. Can strace-ing rm.exe be any good for debugging here? -- Matthias Andree -- 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.7: rm -rf sometimes fails - race condition?
Am 11.12.2010 00:14, schrieb Warren Young: > If you are able to point blame at a specific piece of third-party > software, let us know so it can be added to the BLODA list: > > http://cygwin.com/faq/faq.using.html#faq.using.bloda > > I don't see your specific version of Sophos there. Maybe they fixed > their problems since v7. It could instead mean no one has bothered to > post a credible smoking gun showing the same problems in a later > version. I know if I had problems with Cygwin after installing a later > version of Sophos, I'd just assume it's still broken rather than debug > and re-report it. > >> software that's failing is rm.exe in certain circumstances when running >> "cygport >> fetchmail-6.3.19-1 all", so it's not exactly rocket science I've been trying >> :) > > Point me to your source package, and I'll download it and try building > it in a loop here. Thanks. Note that the official maintenance remains with Jason, I've been toying around with cygport only (your download tool needs to follow HTTP redirects, for curl, use -L; wget should be fine as-is): http://home.pages.de/~mandree/fetchmail/fetchmail-6.3.19-1-src.tar.bz2 -- Matthias Andree -- 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: Suspicious EXE named "[.exe" in c:\cygwin\bin?
Am 12.12.2010 12:29, schrieb Jeffrey Walton:
> Hi Guys,
>
> The executable name is suspicious at best. Attempting to search
On the contrary, it's a standard utility mentioned in IEEE Std 1003.1.
> http://cygwin.com/packages/ results in an error "Invalid regular
> expression search string: `[.exe`". Quotes, double quotes, and back
> ticks do not help during the search.
Problem of the web interface.
> What is this program supposed to do?
The same as "test", except that "[" will expect and consume the closing bracket.
Used in scripting with shells that don't have [ built-in.
Details with "man test" ("man [" is missing on my Cygwin system), or in bash
with "help [".
--
Matthias Andree
--
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
