Nabble - Cygwin list

Re: 1.5.25 under XP Pro SP3: autossh service drops connection immediately after pubkey authentication

2009-11-27T03:59:14Z

Hi Ashton. I haven't been able to fully look into your problem, but it is
unusual and reads like a bunch of permission problems. Here are my best
guesses:

> I've had to set /etc/ssh_config StrictHostKeyChecking to No otherwise
> host key verification will fail.

I think you need to create /etc/ssh/ssh_known_hosts and make it writeable by
SYSTEM.

Or /etc/ssh_known_hosts? Since it appears that you have all of your ssh configs
in /etc instead of /etc/ssh. That is unusual, although I don't think it should
cause any problems for autossh.

> The autossh command line -i switch must look like
> "/cygdrive/c/cygwin/home/Administrator/.ssh/id_rsa" rather than
> "~/.ssh/id_rsa" otherwise it will not find the id_rsa key and the
> connection will fail.

Since your service is running as user SYSTEM, ~ refers to SYSTEM's home, not
Administrator's.

> The previous two problems I've managed to workaround although I dont
> understand why they come up in the first place. In the end however,
> the service manages to start, connects to my Openssh server and
> authenticates, but then immediately drops the connection and the
> autossh service stops. I am running it as a SYSTEM service and I
> believe I've set all the ownership and permissions correctly. Regular
> ssh into my server works correctly. Autossh manually into my server
> works correctly. How do I fix this last problem?

I've looked at the log you provided (thanks for the detailed report), and it's
not clear what's causing the service to stop. It says

debug2: exec request accepted on channel 1
debug2: channel 1: read<=0 rfd 5 len 0
debug2: channel 1: read failed

and it's all downhill from there. About all I can suggest is to try different
users: either change your service to run as Administrator or, preferably, an
unprivileged user (in which case you'll have to change a bunch of key and
directory ownerships); or if you can, run a shell as SYSTEM and see if you can
connect by ordinary ssh.

Please let me know what you find. I'll update the autossh README if I've
overlooked any important advice there.

Last gasp standard advice I guess would be to update to Cygwin 1.7, but I have
no reason to believe that that would change anything, since autossh so far
hasn't even been rebuilt for 1.7.

Good luck,
Andrew.

--
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: tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-27T02:57:02Z

On Fri, Nov 27, 2009 at 09:56:08AM +0100, Corinna Vinschen wrote:

> On Nov 26 19:52, Christopher Faylor wrote:
> > On Fri, Nov 27, 2009 at 01:20:50AM +0100, Reinier Post wrote:
> > >On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
> > >> I wonder if some process has created the file in
> > >> question and still has it open. Then a call to
> > >> create, and a call to unlink, will both fail.
> > >
> > >But the call to open is failing (the fd returned is -1),
> > >which is why the unlink() is executed in the first place,
> > >and it does *not* fail.
> > >
> > >My vote for Stephan Mueller's suggestion that the 'aux' in the
> > >name is causing the problem - but this still doesn't explaing why
> > >the unlink() claims to succeed (returning 0); the loop within tar
> > >should be changed to deal with this situation in any case.
> >
> > No, it shouldn't. We are not going to patch every conceivable
> > program to understand MS-DOS special files.

I am not asking for tar to deal with a special file,
but with a C source code file that happens to be named aux.c.
I'm not even asking for it to write that file, merely not to go
into an infinite loop. I know tar can easily hang on certain input
(e.g. /dev/zero) but I think this particular behavior is not something
users can be expected to work around preventively - a bug.
(I found it by running a script that invokes tar 63000 times overnight,
and tar is often used in such non-interactive contexts.)

Can't this be handled at the system call level?
After all it's not the tar source code but unlink()'s return code
that seems to cause the problem.

> > This won't be a problem with Cygwin 1.7. If you want a fix change
> > to that.

Thank you, I wasn't aware of 1.7.

> Just as a sidenote a pointer to the new User's Guide:
> http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices
>
> Corinna

Very helpful, thank you.

--
Reinier Post

--
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]/usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'

2009-11-27T01:10:42Z

Hello

--- Csaba Raduly wrote:
> What library should I link to overcome the above: undefined reference to `_WinMain@16' ?
>
> You may want to check http://www.bloodshed.net/dev/faq.html#winmain
> There appears to be no .o in that commandline, so there may be no
> main() defined.

I have just notice it. Thanks for comments.

Regards

Tatsuro

--------------------------------------
What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009
http://pr.mail.yahoo.co.jp/banzuke/

--
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: tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-27T00:56:08Z

On Nov 26 19:52, Christopher Faylor wrote:

> On Fri, Nov 27, 2009 at 01:20:50AM +0100, Reinier Post wrote:
> >On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
> >> I wonder if some process has created the file in
> >> question and still has it open. Then a call to
> >> create, and a call to unlink, will both fail.
> >
> >But the call to open is failing (the fd returned is -1),
> >which is why the unlink() is executed in the first place,
> >and it does *not* fail.
> >
> >My vote for Stephan Mueller's suggestion that the 'aux' in the
> >name is causing the problem - but this still doesn't explaing why
> >the unlink() claims to succeed (returning 0); the loop within tar
> >should be changed to deal with this situation in any case.
>
> No, it shouldn't. We are not going to patch every conceivable
> program to understand MS-DOS special files.
>
> This won't be a problem with Cygwin 1.7. If you want a fix change
> to that.

Just as a sidenote a pointer to the new User's Guide:
http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: Problem [1.7]: Inconsistent and wrong results from e.g. ls and md5sum

2009-11-27T00:29:23Z

On Fri, Nov 27, 2009 at 9:22 AM, Fergus wrote:

> cygcheck attached. By the way I also got this output when running cygcheck
> -srv
>
> $ cygcheck -srv > cygcheck.srv
> /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'odserv':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'ose':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'pla':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs':
> Win32 error 5
> Access is denied.

I'm getting the same thing on Vista. I believe it's fairly normal with
UAC and stuff; it may go away if Cygwin was run elevated, but I never
bothered.

Csaba
--
Life is complex, with real and imaginary parts

--
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]/usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'

2009-11-27T00:25:00Z

2009/11/27 Tatsuro MATSUOKA:
> gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o gnuplot-tikz.lua.exe -lpangocairo-1.0 -lcairo
> -lpangoft2-1.0 -lpixman-1 -lglitz -lpng12 -lxcb-render-util -lXrender -lxcb-render -lX11 -lxcb -lXau
> -lXdmcp -lpango-1.0 -lm -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
> -lintl -liconv
> /usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'
>
> What library should I link to overcome the above: undefined reference to `_WinMain@16' ?

You may want to check http://www.bloodshed.net/dev/faq.html#winmain
There appears to be no .o in that commandline, so there may be no
main() defined.

--
Life is complex, with real and imaginary parts

--
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

Problem [1.7]: Inconsistent and wrong results from e.g. ls and md5sum

2009-11-27T00:22:49Z

I am having ongoing problems with file processing using [1.7] with W7 on
FAT32. The problems are not specific to ls and md5sum but may serve to
illustrate a deeper problem. Of course it might be the W7/FAT32 platform
that is inducing the poor behaviours but I would like to try to gather
evidence one way or the other.

1) md5sum shows some files as empty when they are not. When the command
is repeated, different files are wrongly identified:

$ find . -type f | xargs md5sum | grep d41d8cd9
d41d8cd98f00b204e9800998ecf8427e
*./_update-info-dir/_update-info-dir-00820-1-src.tar.bz2
$ find . -type f | xargs md5sum | grep d41d8cd9
d41d8cd98f00b204e9800998ecf8427e
*./gmp/libgmp-devel/libgmp-devel-4.3.0-1.tar.bz2
d41d8cd98f00b204e9800998ecf8427e
*./libggi/libggiwmh0/libggiwmh0-display-x/libggiwmh0-display-x-0.3.2-2.tar.bz2

(. is a very large subdirectory containing many very large files.)

2) If I use ls to see whether, here too, there are any files of size 0
wrongly identified, I get

$ ls -alR | sed '/^d/d' | grep " 0 "
/bin/ls: ./tetex/libkpathsea3/..: Not a directory
$ ls -alR | sed '/^d/d' | grep " 0 "
/bin/ls: ./GNOME/GConf2/GConf2-devel/.: Unknown error 3221225768
/bin/ls: ./X11/XmHTML/libXmHTML0/..: Unknown error 3221225768
/bin/ls: ./_obsolete/octave-headers: Unknown error 3221225768
$ ls -alR | sed '/^d/d' | grep " 0 "
/bin/ls: ./automake/automake1.4: Unknown error 3221225768

Is there some way I can strace these commands or in any way provide
useful illumination to the problem? I am using W7 OS, FAT32 filesystem.
I have downloaded and used (successfully) every current version of
Cygwin since about 2001 but am having such chronic difficulty with [1.7]
on this platform that I think I will probably revert to the more or less
stationery 1.5.25, which would be a great blow. (And "not optimised" for
W7?)

cygcheck attached. By the way I also got this output when running
cygcheck -srv

$ cygcheck -srv > cygcheck.srv
/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'odserv':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'ose':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'pla':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper':
Win32 error 5
Access is denied.
/usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs':
Win32 error 5
Access is denied.

Fergus

--
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

cygcheck.srv.bz2 (26K) Download Attachment

Re: Defunct processes with 1.5.25-15; seemingly reproducible

2009-11-26T23:43:41Z

A <defunct> process is not necesarily the real "problem". All <defunct>
process are processes that their parent has NOT done a wait(2) yet.
Since these <defunct> processes have called exit(2), they must hang
around until a wait(2) is completed so that the exit status can be
returned to the parent.

You need to understand more of the parent/child relationship before
you can pass blame, if any.

Dave Steenburgh wrote:

> cgf wrote:
>
>> Defunct processes are not necessarily indicative of a cygwin problem.
>> This could easily be a problem with gnuplot.
>>
>
> Given the sum of my own limited knowledge of the problem at hand (in
> summary: every program involved is in my local cygwin directory), I
> figured it was best to ask here first.
>
> Dave Steenburgh wrote:
>
>> $ ps
>> PID PPID PGID WINPID TTY UID STIME COMMAND
>> ...
>> 4164 1288 7684 5504 6 1003 23:49:20
>> 5392 3224 5984 6100 5 1003 23:49:06 <defunct>
>> 1452 5240 5984 8104 5 1003 23:49:06 <defunct>
>> 5240 3224 5984 4532 5 1003 23:49:06 <defunct>
>> ...
>>
>>
> ...
>
>> The PIDs seem to be the same every time this happens. Specifically, I
>> have seen 5240 and 1452 every time. Whether that's significant, I
>> don't know.
>>
>
> Now, this is interesting... I killed those defunct processes with
> process explorer, and subsequently confirmed via ps, task manager, and
> process explorer that they were no longer running. I began another
> session with gnuplot, and this time there are three:
>
> $ ps
> ...
> 5240 3224 5984 4532 5 1003 23:49:06 <defunct>
> 4164 1288 7684 5504 6 1003 23:49:20 <defunct>
> 5392 3224 5984 6100 5 1003 23:49:06 <defunct>
> ...
>
> For each of those, the entire row is identical to a row in my previous
> message. Since I started the session around 14:00, and the last
> output file's modification timestamp is 17:21, I'd say the timestamps
> for those three processes are not reliable. Is it possible that the
> original defunct processes were never truly killed? If so, can they
> be killed without rebooting?
>
> --
> 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
>
>
>

--
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

R: [1.7]/usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'

2009-11-26T23:42:25Z

--- Ven 27/11/09, Tatsuro MATSUOKA ha scritto:

> Hello
>
> When linking gnuplot-tikz.lua.exe, which is part of gnuplot
> for a lua related terminal, the following
> error appeared
>
> gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o
> gnuplot-tikz.lua.exe -lpangocairo-1.0
> -lcairo
> -lpangoft2-1.0 -lpixman-1 -lglitz -lpng12 -lxcb-render-util
> -lXrender -lxcb-render -lX11 -lxcb -lXau
> -lXdmcp -lpango-1.0 -lm -lfontconfig -lexpat -lfreetype -lz
> -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
> -lintl -liconv
> /usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined
> reference to `_WinMain@16'
>
> What library should I link to overcome the above: undefined
> reference to `_WinMain@16' ?
>
> Regards
>
> Tatsuro
>

try to move -lm at the end, as you know the order of the lib is
important in cygwin (or in windows in general)

Regards
Marco

--
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]/usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'

2009-11-26T22:24:18Z

Hello

When linking gnuplot-tikz.lua.exe, which is part of gnuplot for a lua related terminal, the following
error appeared

gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o gnuplot-tikz.lua.exe -lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lpixman-1 -lglitz -lpng12 -lxcb-render-util -lXrender -lxcb-render -lX11 -lxcb -lXau
-lXdmcp -lpango-1.0 -lm -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
-lintl -liconv
/usr/lib/libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'

What library should I link to overcome the above: undefined reference to `_WinMain@16' ?

Regards

Tatsuro

--------------------------------------
What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009
http://pr.mail.yahoo.co.jp/banzuke/

--
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: Defunct processes with 1.5.25-15; seemingly reproducible

2009-11-26T21:54:03Z

2009/11/27 Dave Steenburgh <dave.steenburgh@...>

>
> cgf wrote:
> > Defunct processes are not necessarily indicative of a cygwin problem.
> > This could easily be a problem with gnuplot.
>
> Given the sum of my own limited knowledge of the problem at hand (in
> summary: every program involved is in my local cygwin directory), I
> figured it was best to ask here first.
>
> Dave Steenburgh wrote:
> > $ ps
> > PID PPID PGID WINPID TTY UID STIME COMMAND
> > ...
> > 4164 1288 7684 5504 6 1003 23:49:20 <defunct>
> > 5392 3224 5984 6100 5 1003 23:49:06 <defunct>
> > 1452 5240 5984 8104 5 1003 23:49:06 <defunct>
> > 5240 3224 5984 4532 5 1003 23:49:06 <defunct>
> > ...
> >
> ...
> > The PIDs seem to be the same every time this happens. Specifically, I
> > have seen 5240 and 1452 every time. Whether that's significant, I
> > don't know.
>
> Now, this is interesting... I killed those defunct processes with
> process explorer, and subsequently confirmed via ps, task manager, and
> process explorer that they were no longer running. I began another
> session with gnuplot, and this time there are three:
>
> $ ps
> ...
> 5240 3224 5984 4532 5 1003 23:49:06 <defunct>
> 4164 1288 7684 5504 6 1003 23:49:20 <defunct>
> 5392 3224 5984 6100 5 1003 23:49:06 <defunct>
> ...
>
> For each of those, the entire row is identical to a row in my previous
> message. Since I started the session around 14:00, and the last
> output file's modification timestamp is 17:21, I'd say the timestamps
> for those three processes are not reliable. Is it possible that the
> original defunct processes were never truly killed? If so, can they
> be killed without rebooting?
>

Those defunct function will disapear after parent process exist in *nix.
To avoid this condition, try to handle SIGCHLD and call wait/waitpid to
free resources used by child process

--
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: Defunct processes with 1.5.25-15; seemingly reproducible

2009-11-26T21:23:32Z

cgf wrote:
> Defunct processes are not necessarily indicative of a cygwin problem.
> This could easily be a problem with gnuplot.

Given the sum of my own limited knowledge of the problem at hand (in
summary: every program involved is in my local cygwin directory), I
figured it was best to ask here first.

Dave Steenburgh wrote:
> $ ps
> PID PPID PGID WINPID TTY UID STIME COMMAND
> ...
> 4164 1288 7684 5504 6 1003 23:49:20 <defunct>
> 5392 3224 5984 6100 5 1003 23:49:06 <defunct>
> 1452 5240 5984 8104 5 1003 23:49:06 <defunct>
> 5240 3224 5984 4532 5 1003 23:49:06 <defunct>
> ...
>
...
> The PIDs seem to be the same every time this happens. Specifically, I
> have seen 5240 and 1452 every time. Whether that's significant, I
> don't know.

Now, this is interesting... I killed those defunct processes with
process explorer, and subsequently confirmed via ps, task manager, and
process explorer that they were no longer running. I began another
session with gnuplot, and this time there are three:

$ ps
...
5240 3224 5984 4532 5 1003 23:49:06 <defunct>
4164 1288 7684 5504 6 1003 23:49:20 <defunct>
5392 3224 5984 6100 5 1003 23:49:06 <defunct>
...

For each of those, the entire row is identical to a row in my previous
message. Since I started the session around 14:00, and the last
output file's modification timestamp is 17:21, I'd say the timestamps
for those three processes are not reliable. Is it possible that the
original defunct processes were never truly killed? If so, can they
be killed without rebooting?

--
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] cvs over ssh hangs on completion

2009-11-26T20:06:11Z

Here is the tail end of an strace of the hanging cvs process.

Jeremy

--
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

cvs.strace.out (10K) Download Attachment

[1.7] cvs over ssh hangs on completion

2009-11-26T19:42:51Z

I have cvs on a client machine connecting to a host over ssh. The cvs
procedure finishes, but the connection does not terminate until I hit
ctrl-c. The cvs process is then left running on the host. Regular ssh
connections (ie interactive login) do not have this problem.

The host machine is Cygwin 1.7.0 on Windows 7; the client is Cygwin
1.5.25 on Windows XP. Attached is a cygcheck from the host and debug
output from sshd.

Is there anything I can do to fix this?

Thanks,
Jeremy

--
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

cygcheck.out (35K) Download Attachment
sshd.log (5K) Download Attachment

Re: tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-26T16:52:19Z

On Fri, Nov 27, 2009 at 01:20:50AM +0100, Reinier Post wrote:

>On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
>> I wonder if some process has created the file in
>> question and still has it open. Then a call to
>> create, and a call to unlink, will both fail.
>
>But the call to open is failing (the fd returned is -1),
>which is why the unlink() is executed in the first place,
>and it does *not* fail.
>
>My vote for Stephan Mueller's suggestion that the 'aux' in the
>name is causing the problem - but this still doesn't explaing why
>the unlink() claims to succeed (returning 0); the loop within tar
>should be changed to deal with this situation in any case.

No, it shouldn't. We are not going to patch every conceivable
program to understand MS-DOS special files.

This won't be a problem with Cygwin 1.7. If you want a fix change
to that.

cgf

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: Defunct processes with 1.5.25-15; seemingly reproducible

2009-11-26T16:50:47Z

On Thu, Nov 26, 2009 at 01:52:45PM -0500, Dave Steenburgh wrote:

>It is my understanding that this problem is not easily reproducible.
>Well, I've been reproducing it locally since last night. ?I'm going to
>try leaving every cygwin-related process as-is as long as necessary,
>in the hope of beating this problem into submission.
>
>The problem:
>
>$ ps
>? ? ?PID ? ?PPID ? ?PGID ? ? WINPID ?TTY ?UID ? ?STIME COMMAND
>...
>? ? 4164 ? ?1288 ? ?7684 ? ? ? 5504 ? ?6 1003 23:49:20 <defunct>
>? ? 5392 ? ?3224 ? ?5984 ? ? ? 6100 ? ?5 1003 23:49:06 <defunct>
>? ? 1452 ? ?5240 ? ?5984 ? ? ? 8104 ? ?5 1003 23:49:06 <defunct>
>? ? 5240 ? ?3224 ? ?5984 ? ? ? 4532 ? ?5 1003 23:49:06 <defunct>
>...

Defunct processes are not necessarily indicative of a cygwin problem.
This could easily be a problem with gnuplot.

cgf

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-26T16:20:50Z

On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
> I wonder if some process has created the file in
> question and still has it open. Then a call to
> create, and a call to unlink, will both fail.

But the call to open is failing (the fd returned is -1),
which is why the unlink() is executed in the first place,
and it does *not* fail.

My vote for Stephan Mueller's suggestion that the 'aux' in the
name is causing the problem - but this still doesn't explaing why
the unlink() claims to succeed (returning 0); the loop within tar
should be changed to deal with this situation in any case.
Not sure how.

Thanks for your suggestions.

(I'm running the same script on Linux now, if only
because it's running more than 100 times as fast there.
But that has nothing to do with tar bugs.)

--
Reinier Post
TU Eindhoven

--
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

2009-11-26T15:57:29Z

Am 26.11.2009, 16:58 Uhr, schrieb Corinna Vinschen
<corinna-cygwin@...>:

> 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: tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-26T13:39:39Z

I wonder if some process has created the file in
question and still has it open. Then a call to
create, and a call to unlink, will both fail.

You might not see the file until the process
closes it or dies ...

Just a wondering ...

The procexp tool from sysinternals.com might
reveal an open file handle ...

Best wishes -- Eliot Moss

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

RE: tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-26T13:35:06Z

Reinier Post writes:
" curl ftp://ftp.debian.org/debian/pool/main/c/calcoo/calcoo_1.3.16.orig.tar.gz
" | tar zxvf -
"
" hangs after printing the line
"
" calcoo-1.3.16/src/aux.c
"
" This happens on two different i386 systems, both running an up to date Cygwin
" on an up to date Windows XP with the latest security patches applied.
" The file system is NTFS.

The problem is likely related to the fact that Windows won't allow creation of files with names like aux and nul and con (among others) as these are reserved device names.

Cygwin 'Managed Mounts' should help.

stephan();

--
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

tar hangs on unpacking calcoo_1.3.16.orig.tar

2009-11-26T13:30:25Z

Dear list,

I've been using Cygwin daily for years and I'm very happy with it.
But today it threw a nice puzzle at me. I must confess I became
a list member just to report it.

My Cygwin /usr/bin/tar hangs when unpacking an archive:

curl ftp://ftp.debian.org/debian/pool/main/c/calcoo/calcoo_1.3.16.orig.tar.gz
| tar zxvf -

hangs after printing the line

calcoo-1.3.16/src/aux.c

This happens on two different i386 systems, both running an up to date Cygwin
on an up to date Windows XP with the latest security patches applied.
The file system is NTFS.

No such problem exists on Linux.

There must be something odd with this particular archive;
the ones preceding it on the FTP server have no such problem.
But tar should never hang in an infinite loop,
regardless of the input we throw at it.

The same thing happens when the tarball is saved to disk,
gunzipped, and then untarred without the z option.
It also happens with tar-1.20 (current is tar-1.21),
and with tar-1.20 compiled from source, both with and without
Cygwin patches applied. gdb reveals that the problem is in the loop in

src/extract.c

which looks like this (in tar-1.20):

763 do
764 fd = open_output_file (file_name, typeflag, mode ^ invert_permissions);
765 while (fd < 0 && maybe_recoverable (file_name, &interdir_made));

fd is set to -1, which causes maybe_recoverable() to be entered,
which attempts to unlink(file_name), which returns 0 even though
the file does *not* exist, which causes maybe_recoverable() to return 1
and the loop to repeat forever.

I don't know why this is happening, let alone how to repair it.

Does Cygwin have a bugtracker?

Help!

--
Reinier Post
TU Eindhoven

--
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

Defunct processes with 1.5.25-15; seemingly reproducible

2009-11-26T10:52:45Z

It is my understanding that this problem is not easily reproducible.
Well, I've been reproducing it locally since last night. I'm going to
try leaving every cygwin-related process as-is as long as necessary,
in the hope of beating this problem into submission.

The problem:

$ ps
PID PPID PGID WINPID TTY UID STIME COMMAND
...
4164 1288 7684 5504 6 1003 23:49:20 <defunct>
5392 3224 5984 6100 5 1003 23:49:06 <defunct>
1452 5240 5984 8104 5 1003 23:49:06 <defunct>
5240 3224 5984 4532 5 1003 23:49:06 <defunct>
...

$ kill 4164
bash: kill: (4164) - No such process

The PIDs seem to be the same every time this happens. Specifically, I
have seen 5240 and 1452 every time. Whether that's significant, I
don't know.

They all seem to be child processes from a long-running gnuplot
process which creates hundreds---often thousands---of graphs per
session. They do not prevent gnuplot from completing. They do
prevent me from opening some of the output files. Once I kill a
process, its file lock is released, and so far all of the affected
files seem to be just fine.

If anyone would care to pursue this, I will be as helpful as I can.

--
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

cygcheck.out (73K) Download Attachment

Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-66

2009-11-26T07:58:45Z

On Nov 26 15:38, Matthias Andree wrote:

> Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen
> <corinna-cygwin@...>:
>
> >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?

Quote from the announcement for 1.7.0-46, back in May:

What's new in contrast to 1.7.0-46
===================================

- Never use HOMEDRIVE/HOMEPATH to construct a default home directory for
the current user. The mechanism to evaluate the pathname is now:

- If $HOME is already set in the envirnment, use it.
- Otherwise, if /etc/passwd contains a non-empty homedir for the
current user, use it.
- Otherwise, default to /home/<USERNAME>.

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.

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-66

2009-11-26T06:38:01Z

Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen
<corinna-cygwin@...>:

> 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: run: requires CYGWIN=tty?

2009-11-26T06:19:23Z

Corinna Vinschen wrote:
> On Nov 26 10:35, Corinna Vinschen wrote:
>> However, Chuck, can you please try the below patch to run.c instead?
>> It makes the stdout and stderr handles already distinct in run:

I can't reproduce the problem with the original run (my xterm dumps
core, for a different reason), so I've asked the OP to test new binaries
with these 2 changes.

--
Chuck

--
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

Slowness in "wait_sig: entering ReadFile loop" and "parse_options: glob (called func)"

2009-11-26T03:42:41Z

I'm having some serious slowness issues with Cygwin (1.7) on my Windows 7
x64 machine. Background research told me to test things with strace, and
I've noticed that every strace so far gives me major slowness on two
consecutive lines, e.g.:

$ strace ls
[...]
51 2680 [main] ls 3404 time: 1259235257 = time (0)
22954 25634 [sig] ls 3404 wait_sig: entering ReadFile loop, my_readsig
0x170, my_sendsig 0x178
94539 120173 [main] ls 3404 parse_options: glob (called func)
98 120271 [main] ls 3404 parse_options: tty 1001
[...]

$ strace /bin/true
[...]
40 2174 [main] true 3896 time: 1259235243 = time (0)
22838 25012 [sig] true 3896 wait_sig: entering ReadFile loop, my_readsig
0x16C, my_sendsig 0x174
97102 122114 [main] true 3896 parse_options: glob (called func)
86 122200 [main] true 3896 parse_options: tty 1001
[...]

$ strace sh empty.sh
[...]
64 23878 [main] sh 4220 time: 1259235638 = time (0)
1202 25080 [sig] sh 4220 wait_sig: entering ReadFile loop, my_readsig
0x1B0, my_sendsig 0x1B4
119577 144657 [main] sh 4220 parse_options: glob (called func)
142 144799 [main] sh 4220 parse_options: tty 1001
[...]

Also, when running "strace sh empty.sh", I get a massive delay in
gethostname:
151119 388254 [main] sh 4220 cygwin_gethostname: name Leszek-PC

Could any of this be the reason for the slowness, or is it just a red
herring? And for either of those two options, can anyone help?

- Leszek

--
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: run: requires CYGWIN=tty?

2009-11-26T03:04:52Z

On Nov 26 10:35, Corinna Vinschen wrote:

> However, Chuck, can you please try the below patch to run.c instead?
> It makes the stdout and stderr handles already distinct in run:
>
> Index: src/run.c
> ===================================================================
> RCS file: /cvs/cygwin-apps/run/src/run.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 run.c
> --- src/run.c 18 Aug 2009 15:51:05 -0000 1.9
> +++ src/run.c 26 Nov 2009 09:33:11 -0000
> @@ -418,7 +418,10 @@ BOOL configure_startupinfo(STARTUPINFO*
> psi->hStdOutput = CreateFile( "CONOUT$", GENERIC_WRITE | GENERIC_READ,
> FILE_SHARE_WRITE, &sa,
> OPEN_EXISTING, 0, 0 );
> - psi->hStdError = psi->hStdOutput;
> + if (!DuplicateHandle (GetCurrentProcess (), psi->hStdOutput,
> + GetCurrentProcess (), &psi->hStdError,
> + 0, TRUE, DUPLICATE_SAME_ACCESS))
> + psi->hStdError = psi->hStdOutput;
>
> Trace(("Have a console, and not requesting pipes: connecting child stdio to console"));
> return TRUE;

Erm... btw., I would change the sharing flags as well. I don't know
how much influence they have on a console handle, but they certainly
*look* wrong. You can also just simply call CreateFile for the
stderr handle as well, same as for the stdout handle:

Index: src/run.c
===================================================================
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.9
diff -u -p -r1.9 run.c
--- src/run.c 18 Aug 2009 15:51:05 -0000 1.9
+++ src/run.c 26 Nov 2009 11:04:20 -0000
@@ -413,12 +413,14 @@ BOOL configure_startupinfo(STARTUPINFO*

*bUsingPipes = FALSE;
psi->hStdInput = CreateFile( "CONIN$", GENERIC_WRITE | GENERIC_READ,
- FILE_SHARE_READ, &sa,
+ FILE_SHARE_READ | FILE_SHARE_WRITE, &sa,
OPEN_EXISTING, 0, 0 );
psi->hStdOutput = CreateFile( "CONOUT$", GENERIC_WRITE | GENERIC_READ,
- FILE_SHARE_WRITE, &sa,
+ FILE_SHARE_READ | FILE_SHARE_WRITE, &sa,
+ OPEN_EXISTING, 0, 0 );
+ psi->hStdError = CreateFile( "CONOUT$", GENERIC_WRITE | GENERIC_READ,
+ FILE_SHARE_READ | FILE_SHARE_WRITE, &sa,
OPEN_EXISTING, 0, 0 );
- psi->hStdError = psi->hStdOutput;

Trace(("Have a console, and not requesting pipes: connecting child stdio to console"));
return TRUE;

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: run: requires CYGWIN=tty?

2009-11-26T01:35:00Z

On Nov 25 23:44, Charles Wilson wrote:

> Yaakov (Cygwin/X) wrote:
> > I came across this error with run when launched from the cmd prompt with
> > an empty CYGWIN variable:
> >
> > 1 [main] xterm 1248 dtable::stdio_init: couldn't make stderr
> > distinct from stdout
> >
> > If I set CYGWIN=tty then this does not occur. Is this expected?
>
> Not by me. The relevant code in cygwin looks like this:
> [...]
> if (!DuplicateHandle (hMainProc, out, hMainProc, &err, 0, true,
> DUPLICATE_SAME_ACCESS))
> {
> /* If that fails, do this as a fall back. */
> err = out;
> system_printf ("couldn't make stderr distinct from stdout");
> }
>
> So, uhm...DuplicateHandle failed? That seems...strange. Unless the
> handle being duplicated is itself invalid. (e.g. both out and err are
> == INVALID_HANDLE (but then, !not_open(2) should catch that!)
>
> Maybe somebody else will have an A-HA! moment, but without actually
> debugging it this one has me confused.

DuplicateHandle() returns with ERROR_INVALID_PARAMETER. A bit of
experimenting showed that it fails when using the duplicated process
handle hMainProc, but that it does not fail when using
GetCurrentProcess() instead.

So this works:

DuplicateHandle (GetCurrentProcess (), out,
GetCurrentProcess (), &err,
0, true, DUPLICATE_SAME_ACCESS);

But this fails for some reason:

DuplicateHandle (GetCurrentProcess (), GetCurrentProcess (),
GetCurrentProcess (), &hMainProc,
0, FALSE, DUPLICATE_SAME_ACCESS);
DuplicateHandle (hMainProc, out,
hMainProc, &err,
0, true, DUPLICATE_SAME_ACCESS);

I will change that in Cygwin so that this code uses GetCurrentProcess ()
instead of hMainProc.

However, Chuck, can you please try the below patch to run.c instead?
It makes the stdout and stderr handles already distinct in run:

Index: src/run.c
===================================================================
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.9
diff -u -p -r1.9 run.c
--- src/run.c 18 Aug 2009 15:51:05 -0000 1.9
+++ src/run.c 26 Nov 2009 09:33:11 -0000
@@ -418,7 +418,10 @@ BOOL configure_startupinfo(STARTUPINFO*
psi->hStdOutput = CreateFile( "CONOUT$", GENERIC_WRITE | GENERIC_READ,
FILE_SHARE_WRITE, &sa,
OPEN_EXISTING, 0, 0 );
- psi->hStdError = psi->hStdOutput;
+ if (!DuplicateHandle (GetCurrentProcess (), psi->hStdOutput,
+ GetCurrentProcess (), &psi->hStdError,
+ 0, TRUE, DUPLICATE_SAME_ACCESS))
+ psi->hStdError = psi->hStdOutput;

Trace(("Have a console, and not requesting pipes: connecting child stdio to console"));
return TRUE;

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: run: requires CYGWIN=tty?

2009-11-25T20:44:28Z

Yaakov (Cygwin/X) wrote:
> I came across this error with run when launched from the cmd prompt with
> an empty CYGWIN variable:
>
> 1 [main] xterm 1248 dtable::stdio_init: couldn't make stderr
> distinct from stdout
>
> If I set CYGWIN=tty then this does not occur. Is this expected?

Not by me. The relevant code in cygwin looks like this:

/* STD_ERROR_HANDLE has been observed to be the same as
STD_OUTPUT_HANDLE. We need separate handles (e.g. using pipes
to pass data from child to parent). */
/* CV 2008-10-17: Under debugger control, std fd's have been potentially
initialized in dtable::get_debugger_info (). In this case
init_std_file_from_handle is a no-op, so, even if out == err we don't
want to duplicate the handle since it will be unused. */
if (out == err && (!being_debugged () || !not_open (2)))
{
/* Since this code is not invoked for forked tasks, we don't have
to worry about the close-on-exec flag here. */
if (!DuplicateHandle (hMainProc, out, hMainProc, &err, 0, true,
DUPLICATE_SAME_ACCESS))
{
/* If that fails, do this as a fall back. */
err = out;
system_printf ("couldn't make stderr distinct from stdout");
}
}

So, uhm...DuplicateHandle failed? That seems...strange. Unless the
handle being duplicated is itself invalid. (e.g. both out and err are
== INVALID_HANDLE (but then, !not_open(2) should catch that!)

Maybe somebody else will have an A-HA! moment, but without actually
debugging it this one has me confused.

--
Chuck

--
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: cygutils-1.4.1-1

2009-11-25T20:39:56Z

Ken Brown wrote:

>> The new mkshortcut appears to ignore the '-w' option, at least in the
>> example I tried:
>>
>> /usr/bin/mkshortcut -D \
>> -n emacs \
>> -d 'Emacs (X11)' \
>> -w /usr/bin \
>> -i /usr/share/emacs/23.1.50/etc/emacs.ico \
>> -a /usr/share/emacs/23.1.50/etc/emacs.xml \
>> /usr/bin/run2.exe
>>
>> The resulting shortcut had a blank "Start in" box.
>
> Further info: If I delete "-d 'Emacs (X11)'", -w works.

Thanks for the report. I'll look into it.

--
Chuck

--
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

run: requires CYGWIN=tty?

2009-11-25T20:25:28Z

Chuck,

I came across this error with run when launched from the cmd prompt with
an empty CYGWIN variable:

1 [main] xterm 1248 dtable::stdio_init: couldn't make stderr
distinct from stdout

If I set CYGWIN=tty then this does not occur. Is this expected?

Yaakov

--
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: where to find the logrotate package, thanks.

2009-11-25T17:51:55Z

nwpu053821@gmail wrote:
> where to find the logrotate package, thanks.

Hmm, didn't we do this one recently already? Anyway, there isn't a cygwin
port. The canonical logrotate sources live at

https://fedorahosted.org/logrotate/

I didn't try very hard but I did download it and it built and passed most of
its self-tests (failing on #12, "check rotation into a directory given as a
relative pathname", and leaving the remaining two tests untested). I had to
specify "CC=gcc-4" (when building) and "PREFIX=/usr" (when installing) on the
make command-line but no source changes were necessary. So, you might like to
give it a go and see if a homebrew version works for you, but YMMV and there
are at least some problems, I don't know how serious.

cheers,
DaveK

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

where to find the logrotate package, thanks.

2009-11-25T17:18:39Z

where to find the logrotate package, thanks.

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-66

2009-11-25T16:26:27Z

I understand completely now that I know the mirrors operate in "pull" mode.

Larry Hall (Cygwin) wrote:

> On 11/25/2009 04:30 PM, Christopher Faylor wrote:
>> On Wed, Nov 25, 2009 at 03:42:45PM -0500, Paul McFerrin wrote:
>>> I just downloaded cygwin 1.7 and received version -65 instead from
>>> mirror.nyi.net (http). What is wrong?
>>>
>>> .$ uname -v
>>> 2009-11-19 10:07
>>>
>>> Did I catch the download in the middle of a critical update?
>>
>> Huh? No. Mirrors use a pull mechanism, not a push mechanism. If the
>> mirror doesn't have the latest version of cygwin that means it hasn't
>> pulled it from cygwin.com yet.
>
> Chris, you just beat me to this. :-) The only thing I'd add is you
> need to
> either be more patient
> (<http://cygwin.com/ml/cygwin/2009-11/msg00842.html>)
> or more vigilant/exhaustive in your search. In the vigilant/exhaustive
> category, you would have found what you were looking for with this mirror
> <http://cygwin.elite-systems.org/>. Of course, I'm not saying this
> mirror will
> always be the most up-to-date. That's where the "exhaustive" part comes
> in. ;-)
>

--
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

2009-11-25T13:38:30Z

On 11/25/2009 04:30 PM, Christopher Faylor wrote:

> On Wed, Nov 25, 2009 at 03:42:45PM -0500, Paul McFerrin wrote:
>> I just downloaded cygwin 1.7 and received version -65 instead from
>> mirror.nyi.net (http). What is wrong?
>>
>> .$ uname -v
>> 2009-11-19 10:07
>>
>> Did I catch the download in the middle of a critical update?
>
> Huh? No. Mirrors use a pull mechanism, not a push mechanism. If the
> mirror doesn't have the latest version of cygwin that means it hasn't
> pulled it from cygwin.com yet.

Chris, you just beat me to this. :-) The only thing I'd add is you need to
either be more patient (<http://cygwin.com/ml/cygwin/2009-11/msg00842.html>)
or more vigilant/exhaustive in your search. In the vigilant/exhaustive
category, you would have found what you were looking for with this mirror
<http://cygwin.elite-systems.org/>. Of course, I'm not saying this mirror will
always be the most up-to-date. That's where the "exhaustive" part comes
in. ;-)

--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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