socket not closed in a threaded server

[sylvain DELHOMME]

While playing with sockets and threads, I noticed that while my tcp socket is 
correctly closed, the associated udp socket (managed by Cygwin) is not. This 
was tested with(out) Firewall && Antivirus on 2 WinXP computers with cygwin 
1.5.25.

Is that a known problem with Cygwin (code is fine under Linux Debian) ?

testcase :

- ./main.exe (netstat shows 2 sockets (one tcp on port 1025 && one udp)
- telnet 127.0.0.1 1025 (netstat shows 4 sockets  : 2 tcp && 2 udp )
- netstat -ab shows 3 sockets (one tcp on port 1025 && two udp).

src :

--- begin ---

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define MAXTHREADS 4

pthread_mutex_t __mutex = PTHREAD_MUTEX_INITIALIZER;

struct thrdata {
int thrnum;
pthread_t t;
int socket_fd;
int socket_errno;
}th[MAXTHREADS];

int thread_code( void *p );

int main(int argc, char **argv)
{
int fd;
struct sockaddr_in sa;
int i;

sa.sin_family = AF_INET;
sa.sin_addr.s_addr = htonl(INADDR_ANY);
sa.sin_port = htons(1025);

fd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

printf("socket id : %d\n", fd);

if( bind( fd, (struct sockaddr *)&sa, sizeof(sa) ) == -1 )
printf("bind error\n");

if( listen( fd, 0 ) == -1 )
printf("listen error\n");

printf("creating threads\n");

for(i=0; isocket_fd;
int fd_client;
struct sockaddr_in sa_client;
int sin_size;
int i;
char buf;

// printf("thread, fd : %d\n", fd);

for( ;; )
{
pthread_mutex_lock(&__mutex); /* begin critical area */ 
fd_client = accept( fd, (struct sockaddr *)&sa_client, 
&sin_size );

if( fd_client < 0 )
printf("accept error\n");

pthread_mutex_unlock(&__mutex); /* end critical area */

if( fd_client > 0 )
{
printf("accept fd : %d, fd_client : %d\n", fd, 
fd_client );
for(i=0; i<20; i++)
{
send( fd_client, "hello\n", strlen("hello"), 0 
);
sleep(1);
}

printf("closing fd_client : %d\n", fd_client );
close( fd_client );
}
}

return 1;
}

--- end ---

--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Dirk Napierala]

First of all sorry if we missed to answer a question before.
But as you said: (which wouldn't be surprising given the amount of noise 
on this thread)

Trying to be more accurate from now on :-)


Christopher Faylor schrieb:


On Wed, Sep 24, 2008 at 06:51:28PM +0200, Dirk Napierala wrote:
  

Hello again,

I think it would be the best to give this topic a new start from scratch
trying to add some more input from our side.

We discovered an issue  trying to open big selfextracting zip files.
Trying to do so result in the following error:

./*selfextracting_zipfile*.exe
bash: ./*selfextracting_zipfile*.exe: Cannot allocate memory

using other methods to launch the file (like unzip or cmd /c) is not an
option due to company internals.
Also rebuilding the zip file or span it is not an option. We have to use
the zip file as it is and it have
to be started as mentiond above.
(I know this is somehow stupid, but thats the way it is and we are
unfortunately  not able to change this fact
Please don't let us take this into the discussion)

But  just to let you know, using unzip or cmd /c to start it is working
well. (Indicator for a bash issue ???)

This only happens to huge files (guess the limit is  above 1.5GB size)
The one we are currently trying is 1,75 GB (1.883.969.903 Bytes)
Smaller once are working fine.

Following the guidline "Changing Cygwin's Maximum Memory"  from
http://cygwin.com/cygwin-ug-net/setup-maxmem.html
the result of maxmem is
$ ./maxmem.exe
5fffe000 bytes (1536.0Mb)
(same result on a 2GB system as well as on a 4GB system)
changing this by
regtool -i set /HKLM/Software/Cygnus\ Solutions/Cygwin/heap_chunk_in_mb 
1024



Why would you expect that setting the memory size to LESS than the size of
the zip file would work?

  
From what we understand by reading the guideline "Changing Cygwin's 
Maximum Memory" the result
of the small program written by DJ Delorie  tests the memory allocation 
limit on your system.
Running the program will output the maximum amount of allocatable memory 
of your system.
Doing so on several test systems and the different cygwin versions the 
result is _always _1536.
Trying it for example with 2500MB setting on a 4GB system also failed 
with "Cannot allocate memory".



or
regtool -i set /HKLM/Software/Cygnus\ Solutions/Cygwin/heap_chunk_in_mb 
1536

followed by a reboot did not solve the issue.



Ditto.

It probably will not make a difference but it seems like you really should
be trying to set the size to something noticeably larger than the size of
your gzip files.

  

Done, without success.

It happens on the current version available for download 1.5.25-15
and also with the new 1.7.0 (base-files version 3.7-1)(thanks to Volker
Zell providing us this one for testing)

If we are using an older version instead (1.5.18 base-files version
3.6-1) this issue doesn't show up.
It seems to be hardware and memory amount independent. Tested on several
Dell desktop systems with 2GB
and finaly on my Laptop with 4GB memory.

Looking forward to a cygwin developer to troubleshoot this.
Thanks in advance for any constructive feeback.



I am a developer.  I responded to you here.

http://cygwin.com/ml/cygwin/2008-09/msg00511.html
  
How are the files created?

The files are created using using Winzip and WinZip Self Extractor

  Are the self-extracting
executables cygwin executables or windows executables?

Windows executables



  What version of
zip was used to create the files?

Unknown to us, because we just get this files provided by another department

  Have you tried a newer version?
  
Just to see if the SFX zip is the root cause we recreated it with Winzip 
version 11.1
and WinZip Self Extractor 3.1 without finally getting rid of the cygwin 
"Cannot allocate memory" message.

So the SFX file itself doesn't seem to cause this problem.


You still need to provide some details.
  
Hopefully we do not miss something again this time. If you feel to need 
more input, just let us know.

cgf

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

  


--
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: Cannot build ftgl-2.1.3~rc5

[Dave Korn]

Tatsuro MATSUOKA wrote on 19 September 2008 08:50:

> Hello
> 
> I could not  build ftgl-2.1.3~rc5.

> FTVectoriser.cpp: In member function 'void
> FTVectoriser::MakeMesh(FTGL_DOUBLE, int, float)': FTVectoriser.cpp:275:
> error: invalid conversion from 'GLvoid (*)()' to 'void (*)()'
> FTVectoriser.cpp:275: error:   initializing argument 3 of 'void
> gluTessCallback(GLUtesselator*, GLenum, void (*)())' 
> FTVectoriser.cpp:276: error: invalid conversion from 'GLvoid (*)()' to
> 'void (*)()' FTVectoriser.cpp:276: error:   initializing argument 3 of
> 'void gluTessCallback(GLUtesselator*, GLenum, void (*)())'
> FTVectoriser.cpp:277: error: invalid conversion from 'GLvoid (*)()' to
> 'void (*)()' FTVectoriser.cpp:277: error:   initializing argument 3 of
> 'void gluTessCallback(GLUtesselator*, GLenum, void (*)())'
> FTVectoriser.cpp:278: error: invalid conversion from 'GLvoid (*)()' to
> 'void (*)()' FTVectoriser.cpp:278: error:   initializing argument 3 of
> 'void gluTessCallback(GLUtesselator*, GLenum, void (*)())'
> FTVectoriser.cpp:279: error: invalid conversion from 'GLvoid (*)()' to
> 'void (*)()' FTVectoriser.cpp:279: error:   initializing argument 3 of
> 'void gluTessCallback(GLUtesselator*, GLenum, void (*)())'

> on gcc-3.4.4-3 the same error occurred.
> 
> However on mingw, I could build it after some modification about opengl
> on windows. FTVectoriser.cpp was comliped without errors on mingw.
> 
> So it seems that it is a gcc on cygwin specfic issue.
> 
> How can I overcome this issue?

  This sounds like the sort of C++ compat issue that might be given leeway by
adding -fpermissive to your CXXFLAGS.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: socket not closed in a threaded server

[Dave Korn]

sylvain DELHOMME wrote on 25 September 2008 09:23:

> While playing with sockets and threads, I noticed that while my tcp
> socket is correctly closed, the associated udp socket (managed by Cygwin)
> is not. This was tested with(out) Firewall && Antivirus on 2 WinXP
> computers with cygwin 1.5.25.
> 
> Is that a known problem with Cygwin (code is fine under Linux Debian) ?

  The "associated udp" socket is an internal thing managed by winsock; it's
standard OS behaviour and happens to native win32 programs as well.  It's used
for some kind of internal loopbacky rpc-ish thingy and you can ignore it.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Dave Korn]

Dirk Napierala wrote on 25 September 2008 09:55:

>  From what we understand by reading the guideline "Changing Cygwin's
> Maximum Memory" the result
> of the small program written by DJ Delorie  tests the memory allocation
> limit on your system.
> Running the program will output the maximum amount of allocatable memory
> of your system.
> Doing so on several test systems and the different cygwin versions the
> result is _always _1536.
> Trying it for example with 2500MB setting on a 4GB system also failed
> with "Cannot allocate memory".

  There is an upper limit imposed by the dividing point between kernel and
user space at the 2GB mark.  You can try adding the /3GB flag in boot.ini to
raise this by a further gig.  You might need also to make extensive use of
rebaseall to ensure your DLLs end up at the upper end of that range and don't
fragment the space, or it might not matter, depending on the patterns of
memory usage of the unpacker.

>> It probably will not make a difference but it seems like you really
>> should be trying to set the size to something noticeably larger than the
>> size of your gzip files. 
>> 
>> 
> Done, without success.

  This might then work better.

> So the SFX file itself doesn't seem to cause this problem.

  Random and wacky idea: What happens if you prepend Cygwin's
/bin/unzipsfx.exe to the existing SFX and try running that?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Marco Atzeri]

--- Dave Korn  ha scritto:

> Dirk Napierala wrote on 25 September 2008 09:55:
> 
> > So the SFX file itself doesn't seem to cause this
> problem.
> 
>   Random and wacky idea: What happens if you prepend
> Cygwin's
> /bin/unzipsfx.exe to the existing SFX and try
> running that?
> 
> cheers,
>   DaveK

other wacky idea
cygwin 7z is able to handle self extracting
archive and 2G zip file

7z x yourfile.exe

not tested with 2G self extracting exe 
as Winzip trial refuse to build one
so large 
:-)

Regards
Marco

__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Dirk Napierala]

Dave Korn schrieb:

Dirk Napierala wrote on 25 September 2008 09:55:

  

 From what we understand by reading the guideline "Changing Cygwin's
Maximum Memory" the result
of the small program written by DJ Delorie  tests the memory allocation
limit on your system.
Running the program will output the maximum amount of allocatable memory
of your system.
Doing so on several test systems and the different cygwin versions the
result is _always _1536.
Trying it for example with 2500MB setting on a 4GB system also failed
with "Cannot allocate memory".



  There is an upper limit imposed by the dividing point between kernel and
user space at the 2GB mark.  You can try adding the /3GB flag in boot.ini to
raise this by a further gig.  You might need also to make extensive use of
rebaseall to ensure your DLLs end up at the upper end of that range and don't
fragment the space, or it might not matter, depending on the patterns of
memory usage of the unpacker.
  
It is not about that we would not like to test such kind of workarounds 
it is more the fact that settings
like /3GB flag in boot.ini are out of our control (you know huge 
company's and internal politic restrictions
are limiting us very much in implementing such a fix. We don't like it 
either, but that is the way it is unfortunately)


Anyway even if this would help, it doesn't explain, why on the same 
system, without any other change than
switching the cygwin versions, it works with the old one and doesn't 
work with the current one.


The only thing that have changed on this systems is the cygwin version. 
Old one woks new one doesn't
It is worse trying to tell somebody to change his code due to the fact 
that a new version of cygwin should

be used in the future.
There are also a lot of other valid points for us, But please let us not 
that that into the discussion.

There are always reasons pro & contra doing it this or that way.
But if you are limited in the things you are allowed to do, than there 
is sometimes no

other chance than trying to fix it within you restricted possibility's.

  

It probably will not make a difference but it seems like you really
should be trying to set the size to something noticeably larger than the
size of your gzip files. 



  

Done, without success.



  This might then work better.

  

So the SFX file itself doesn't seem to cause this problem.



  Random and wacky idea: What happens if you prepend Cygwin's
/bin/unzipsfx.exe to the existing SFX and try running that?
  


If we test it try to do it using unzip or cmd /c for example it is 
working fine.
But also at this point would not help us as a workaround due to the fact 
that
the SFX file is called withing cygwin bash by a another (out of our 
control) programm

that we can not change ourself.



cheers,
  DaveK
  


--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Dirk Napierala]

Marco Atzeri schrieb:

--- Dave Korn  ha scritto:

  

Dirk Napierala wrote on 25 September 2008 09:55:



So the SFX file itself doesn't seem to cause this
  

problem.

  Random and wacky idea: What happens if you prepend
Cygwin's
/bin/unzipsfx.exe to the existing SFX and try
running that?

cheers,
  DaveK



other wacky idea
cygwin 7z is able to handle self extracting
archive and 2G zip file

7z x yourfile.exe

not tested with 2G self extracting exe 
as Winzip trial refuse to build one
so large 
:-)


  
It is not about that we would not like to test such kind of workarounds 
it is more the fact they
are out of our control (you know huge company's and internal politic 
restrictions are limiting us very
much in implementing such a fix. We don't like it either, but that is 
the way it is unfortunately)


Even if this would help, it doesn't explain, why on the same system, 
without any other change than
switching the cygwin versions, it works with the old one and doesn't 
work with the current one
It is worse trying to tell somebody to change his code due to the fact 
that a new version of cygwin should

be used in the future.


The SFX file is called withing cygwin bash by a another (out of our 
control) programm

that we can not change ourself.
And as the only different on the system is, one time using the old one, 
and the other time the new one,

it would be hard to explain to someone to change his code due to that.



Regards
Marco

__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 


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

  


--
Oracle 
Dirk Napierala | Senior Support Consultant
Phone: +4921174839542 | Fax: +4921174839422 | Mobile: +491775946542
Oracle Global IT / Service Design Grid Services Infrastructure & Automation

ORACLE Deutschland GmbH | Hamborner Straße 51 | 40472 Düsseldorf

ORACLE Deutschland GmbH, Hauptverwaltung: Riesstraße 25, D-80992 München
Geschäftsführer: Jürgen Kunz, Registergericht: Amtsgericht München, HRB 
82775
Green Oracle  	Oracle is committed to 
developing practices and products that help protect the environment




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

reg: RSH on windows (password less)

[Manjunatha Appaji Gowda]

Hi all,

I am trying  password less login from Linux machine to windows, I have
configured the inted as per the steps you have given under readme file,
all packages are updated. But whenever I tried to login in to the
windows machine it will ask for the password. I have created .rhoosts
file n kept in the home dir with 644 and 600 permission. 

Here the package details 

inetutils1.5-3  OK
login1.9-8  OK

I can find the below logs 

Sep 25 17:01:58 machiename rlogind: PID 3272: Connect from
xx.xx.xx.xx:1008
Sep 25 17:02:01 machinename rlogind: PID 3272: iruserok failed:
rusername=xxx
e, lusername=

any suggestions please

thanks
Manjunath A


--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Marco Atzeri]

--- Dirk Napierala  ha scritto:

> 
> Even if this would help, it doesn't explain, why on
> the same system, 
> without any other change than
> switching the cygwin versions, it works with the old
> one and doesn't 
> work with the current one

to eventually try to identify the change that broken
your system, it will be useful to know

- last cygwin version that was able to handle it
- first version that is unable

On some mirrors, version from 
1.5.15-1 to 1.5.25-15
are available 
(they are 3 years of cygwin changes)

ftp://ftp.funet.fi/pub/mirrors/cygwin.com/pub/cygwin/release/cygwin/

Regards
Marco




__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Dave Korn]

Dirk Napierala wrote on 25 September 2008 11:58:

> it is more the fact that settings
> like /3GB flag in boot.ini are out of our control (you know huge
> company's and internal politic restrictions

  Yeh, gotcha.

> Anyway even if this would help, it doesn't explain, why on the same
> system, without any other change than
> switching the cygwin versions, it works with the old one and doesn't
> work with the current one.

  Yeh, there must be some kind of different memory layout going on.  Have you
run the rebaseall procedure on either/both of the installations?

>>   Random and wacky idea: What happens if you prepend Cygwin's
>> /bin/unzipsfx.exe to the existing SFX and try running that?
>> 
> 
> If we test it try to do it using unzip or cmd /c for example it is
> working fine.
> But also at this point would not help us as a workaround due to the fact
> that
> the SFX file is called withing cygwin bash by a another (out of our
> control) programm that we can not change ourself.

  Yes, but can you not preprocess the sfx files before handing them over to
that other program?  You don't need to worry about stripping off the native
sfx header either, it should just work to prefix the cygwin one.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: socket not closed in a threaded server

[Sylvain Delhomme]

> The "associated udp" socket is an internal thing managed by winsock; it's
>standard OS behaviour and happens to native win32 programs as well. 

I've just ported my small app to Winsock and I did not see this.

> It's
> used for some kind of internal loopbacky rpc-ish thingy and you can ignore
> it.
>

Could you provide me more info about this because it can be quite annoying in 
a real application ?


 



--
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: socket not closed in a threaded server

[Dave Korn]

Sylvain Delhomme wrote on 25 September 2008 13:57:

>> The "associated udp" socket is an internal thing managed by winsock; it's
>> standard OS behaviour and happens to native win32 programs as well.
> 
> I've just ported my small app to Winsock and I did not see this.

  Hmm, odd, but it's a well known phenomenon.  Here's an example showing
solely the use of cmd.exe and iexplore.exe; Cygwin not involved at all except
for the diff command at the end.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\dk>netstat -ano > before.txt

C:\Documents and Settings\dk>"\Program Files\Internet Explorer\iexplore.exe"

C:\Documents and Settings\dk>netstat -ano > after.txt

C:\Documents and Settings\dk>diff -pu before.txt after.txt
--- before.txt  2008-09-25 14:28:39.829644300 +0100
+++ after.txt   2008-09-25 14:28:50.955000300 +0100
@@ -27,6 +27,7 @@ Active Connections
   UDP127.0.0.1:1025 *:*600
   UDP127.0.0.1:1028 *:*1108
   UDP127.0.0.1:1056 *:*1052
+  UDP127.0.0.1:2301 *:*2388
   UDP127.0.0.1:2584 *:*1580
   UDP192.168.1.150:123  *:*1580
   UDP192.168.1.150:137  *:*4

C:\Documents and Settings\dk>


  As you see, even when not showing a page (launching iexplore.exe =
about:blank on my machine), it has an open UDP socket.

  Sorry, I don't have a source right now; I'll keep looking.  I'm writing off
the top of my head, and I just remembered that possibly it's not even a
loopback connection, it may just be some artifact of windows netstat.  I'll
post again if I can find a reference.

 
>> It's
>> used for some kind of internal loopbacky rpc-ish thingy and you can
>> ignore it. 
>> 
> 
> Could you provide me more info about this because it can be quite
> annoying in a real application ?

  What kind of "annoying"?  It does no harm and requires no action on your
part TTBOMK.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Error running cvs commands from crontab

[Senthil Kuppusamy]

Hi,

 I was trying to update my project
directory from remote cvs server like "cvs -d
[EMAIL PROTECTED]:/home/cvsroot/ my_project" and getting following error

Errror log
Runs commands on remote hosts running the RSH service. RSH host [-l
username] [-n] command host Specifies the remote host on which to run
command. -l username Specifies the user name to use on the remote
host. If omitted, the logged on user name is used. -n Redirects the
input of RSH to NULL. command Specifies the command to run. cvs
[update aborted]: end of file from server (consult above messages if
any)

When I tried to run from command prompt it runs. Running through
crontab throws this issue
I have used the same cvs path from CVSROOT variable. Also using the
same cvs user account on both occasions.

Thanks,
Senthil.

--
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: Error running cvs commands from crontab

[Dave Korn]

Senthil Kuppusamy wrote on 25 September 2008 15:07:

>  I was trying to update my project
> directory from remote cvs server like "cvs -d
> [EMAIL PROTECTED]:/home/cvsroot/ my_project" and getting following error
> 
> Errror log
> Runs commands on remote hosts running the RSH service. RSH host [-l
> username] [-n] command host Specifies the remote host on which to run
> command. -l username Specifies the user name to use on the remote
> host. If omitted, the logged on user name is used. -n Redirects the
> input of RSH to NULL. command Specifies the command to run. cvs
> [update aborted]: end of file from server (consult above messages if
> any)
> 
> When I tried to run from command prompt it runs. Running through
> crontab throws this issue
> I have used the same cvs path from CVSROOT variable. Also using the
> same cvs user account on both occasions.


  What about CVS_RSH?  Is that maybe set to 'ssh' in one case and not in the
other?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Bug in grep when -i used with -o and/or --color=auto

[Christopher Faylor]

On Wed, Sep 24, 2008 at 05:55:35PM -0600, Eric Blake wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Gary Johnson on 9/24/2008 5:17 PM:
>> Cygwin's grep appears to give incorrect results when given the -i 
>> option in combination with the --color=auto and/or -o options.
>
>This is a known upstream bug in grep, which has since been fixed upstream.
> Upstream is now at 2.5.3, so maybe it's time for the cygwin grep package
>maintainer to roll a new release.

I'll get to that this weekend.

cgf

--
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: Error running cvs commands from crontab

[Allan Schrum]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Senthil Kuppusamy
> Sent: Thursday, September 25, 2008 10:07 AM
> To: cygwin@cygwin.com
> Subject: Error running cvs commands from crontab
> 
> Hi,
> 
>  I was trying to update my project
> directory from remote cvs server like "cvs -d
> [EMAIL PROTECTED]:/home/cvsroot/ my_project" and getting following
error
> 
> Errror log
> Runs commands on remote hosts running the RSH service. RSH host [-l
> username] [-n] command host Specifies the remote host on which to run
> command. -l username Specifies the user name to use on the remote
> host. If omitted, the logged on user name is used. -n Redirects the
> input of RSH to NULL. command Specifies the command to run. cvs
> [update aborted]: end of file from server (consult above messages if
> any)
> 
> When I tried to run from command prompt it runs. Running through
> crontab throws this issue
> I have used the same cvs path from CVSROOT variable. Also using the
> same cvs user account on both occasions.
> 
> Thanks,
> Senthil.

Traditionally cron runs under a reduced environment that typically does
not match an interactive environment. Many environment variables are
missing which may affect how the cron job runs. Perhaps if you create a
small command file to print out all your environment variables under
cron and compare that with your interactive environment you may find the
clue which helps. Typically, the PATH variable does not include what you
need to make things work. Since RSH is mentioned, you may need to define
the CVS_RSH variable to make this work under cron.

Rather than run the "cvs" command directly in cron, put it into a
command script where you can control the environment as desired and then
run the script from cron. This helps avoid some of the syntax hazards of
very complex cron commands.

Regards,

-Allan

--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Christopher Faylor]

On Thu, Sep 25, 2008 at 10:29:56AM +0100, Dave Korn wrote:
>Dirk Napierala wrote on 25 September 2008 09:55:
>
>>  From what we understand by reading the guideline "Changing Cygwin's
>> Maximum Memory" the result
>> of the small program written by DJ Delorie  tests the memory allocation
>> limit on your system.
>> Running the program will output the maximum amount of allocatable memory
>> of your system.
>> Doing so on several test systems and the different cygwin versions the
>> result is _always _1536.
>> Trying it for example with 2500MB setting on a 4GB system also failed
>> with "Cannot allocate memory".
>
>  There is an upper limit imposed by the dividing point between kernel and
>user space at the 2GB mark.  You can try adding the /3GB flag in boot.ini to
>raise this by a further gig.  You might need also to make extensive use of
>rebaseall to ensure your DLLs end up at the upper end of that range and don't
>fragment the space, or it might not matter, depending on the patterns of
>memory usage of the unpacker.

Right.  Also, the User's Guide entry is out of date.  The example maxmem
allocator won't tell you what the maximum contiguous amount of memory
possible could be.  That's what the heap_chunk_in_mb sets.  The new
malloc allows discontiguous allocation but is still limited to available
memory holes.

cgf

--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Christopher Faylor]

On Thu, Sep 25, 2008 at 01:11:37PM +0200, Dirk Napierala wrote:
> Marco Atzeri schrieb:
>> --- Dave Korn  ha scritto:
>>
>>   
>>> Dirk Napierala wrote on 25 September 2008 09:55:
>>>
>>> 
 So the SFX file itself doesn't seem to cause this
   
>>> problem.
>>>
>>>   Random and wacky idea: What happens if you prepend
>>> Cygwin's
>>> /bin/unzipsfx.exe to the existing SFX and try
>>> running that?
>>>
>>> cheers,
>>>   DaveK
>>> 
>>
>> other wacky idea
>> cygwin 7z is able to handle self extracting
>> archive and 2G zip file
>>
>> 7z x yourfile.exe
>>
>> not tested with 2G self extracting exe as Winzip trial refuse to build one
>> so large :-)
>
>It is not about that we would not like to test such kind of workarounds
>it is more the fact they are out of our control (you know huge
>company's and internal politic restrictions are limiting us very much
>in implementing such a fix.  We don't like it either, but that is the
>way it is unfortunately)
>
>Even if this would help, it doesn't explain, why on the same system,
>without any other change than switching the cygwin versions, it works
>with the old one and doesn't work with the current one It is worse
>trying to tell somebody to change his code due to the fact that a new
>version of cygwin should be used in the future.

I don't see a real solution for you here if you are this limited.  We
are not going to be rolling a new version of 1.5.x.  and it is unlikely
that there will be a magic option (with the possible exception of Dave's
/3GB suggestion) that will fix this for you.

cgf

--
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: socket not closed in a threaded server

[Sylvain Delhomme]

>   Hmm, odd, but it's a well known phenomenon.  Here's an example showing
> solely the use of cmd.exe and iexplore.exe; Cygwin not involved at all
> except for the diff command at the end.
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\Documents and Settings\dk>netstat -ano > before.txt
>
> C:\Documents and Settings\dk>"\Program Files\Internet
> Explorer\iexplore.exe"
>
> C:\Documents and Settings\dk>netstat -ano > after.txt
>
> C:\Documents and Settings\dk>diff -pu before.txt after.txt
> --- before.txt  2008-09-25 14:28:39.829644300 +0100
> +++ after.txt   2008-09-25 14:28:50.955000300 +0100
> @@ -27,6 +27,7 @@ Active Connections
>UDP127.0.0.1:1025 *:*600
>UDP127.0.0.1:1028 *:*   
> 1108 UDP127.0.0.1:1056 *:*   
> 1052 +  UDP127.0.0.1:2301 *:*  
>  2388 UDP127.0.0.1:2584 *:*   
> 1580 UDP192.168.1.150:123  *:*   
> 1580 UDP192.168.1.150:137  *:*4
>
> C:\Documents and Settings\dk>
>
>
>   As you see, even when not showing a page (launching iexplore.exe =
> about:blank on my machine), it has an open UDP socket.
>
>   Sorry, I don't have a source right now; I'll keep looking.  I'm writing
> off the top of my head, and I just remembered that possibly it's not even a
> loopback connection, it may just be some artifact of windows netstat.  I'll
> post again if I can find a reference.

Thanks for the explanation. I am going to test my winsock test program again.

>
> >> It's
> >> used for some kind of internal loopbacky rpc-ish thingy and you can
> >> ignore it.
> >
> > Could you provide me more info about this because it can be quite
> > annoying in a real application ?
>
>   What kind of "annoying"?  It does no harm and requires no action on your
> part TTBOMK.

Nevermind, i did not test enough to see that one connection did no left one 
open udp socket. In my testcase there are no more than 4 udp socket left 
open. So i guess there is no problem...

Thanks,
Sylvain

 





--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Christopher Faylor]

On Thu, Sep 25, 2008 at 12:57:32PM +0200, Dirk Napierala wrote:
> Dave Korn schrieb:
>> Dirk Napierala wrote on 25 September 2008 09:55:
>>
>>   
>>>  From what we understand by reading the guideline "Changing Cygwin's
>>> Maximum Memory" the result
>>> of the small program written by DJ Delorie  tests the memory allocation
>>> limit on your system.
>>> Running the program will output the maximum amount of allocatable memory
>>> of your system.
>>> Doing so on several test systems and the different cygwin versions the
>>> result is _always _1536.
>>> Trying it for example with 2500MB setting on a 4GB system also failed
>>> with "Cannot allocate memory".
>>> 
>>
>>   There is an upper limit imposed by the dividing point between kernel and
>> user space at the 2GB mark.  You can try adding the /3GB flag in boot.ini 
>> to
>> raise this by a further gig.  You might need also to make extensive use of
>> rebaseall to ensure your DLLs end up at the upper end of that range and 
>> don't
>> fragment the space, or it might not matter, depending on the patterns of
>> memory usage of the unpacker.
>>   
>It is not about that we would not like to test such kind of workarounds
>it is more the fact that settings like /3GB flag in boot.ini are out of
>our control (you know huge company's and internal politic restrictions
>are limiting us very much in implementing such a fix.  We don't like it
>either, but that is the way it is unfortunately)
>
>Anyway even if this would help, it doesn't explain, why on the same
>system, without any other change than switching the cygwin versions, it
>works with the old one and doesn't work with the current one.

We are trying to do something called "debugging" here and you are not
making it especially easy.  If you could somehow test the above, it
would give us a data point that might be a clue as to what the problem
could be.

>The only thing that have changed on this systems is the cygwin version.
>Old one woks new one doesn't

You are talking about upgrading to 1.5.25-15 but presumably you upgraded
more than just the DLL so there are a quite a few possible other
candidates.

If you are really just swapping back and forth between different DLLs
then you need to provide EXACT details of what you are doing.  You have
not provided cygcheck output although I did point you to the problem
reporting web page which asks for that.  cygcheck output for the working
and non-working systems would be useful.

cgf

--
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: Bug in grep when -i used with -o and/or --color=auto

[Gary Johnson]

On 2008-09-25, Christopher Faylor wrote:
> On Wed, Sep 24, 2008 at 05:55:35PM -0600, Eric Blake wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >According to Gary Johnson on 9/24/2008 5:17 PM:
> >> Cygwin's grep appears to give incorrect results when given the -i 
> >> option in combination with the --color=auto and/or -o options.
> >
> >This is a known upstream bug in grep, which has since been fixed upstream.
> > Upstream is now at 2.5.3, so maybe it's time for the cygwin grep package
> >maintainer to roll a new release.
> 
> I'll get to that this weekend.

Thank you.

Regards,
Gary


--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Dirk Napierala]

Marco Atzeri schrieb:

--- Dirk Napierala  ha scritto:

  

Even if this would help, it doesn't explain, why on
the same system, 
without any other change than

switching the cygwin versions, it works with the old
one and doesn't 
work with the current one



to eventually try to identify the change that broken
your system, it will be useful to know

- last cygwin version that was able to handle it
- first version that is unable

On some mirrors, version from 
1.5.15-1 to 1.5.25-15
are available 
(they are 3 years of cygwin changes)


ftp://ftp.funet.fi/pub/mirrors/cygwin.com/pub/cygwin/release/cygwin/
  
Following your link now having the different versions available we were 
able to narrow down the issue to cygwin1.dll

The point of failure is 1.5.19-4. This is the first one with this problem
while1.5.18-1 is the last one working well.

1.5.18-1 = O.K
1.5.19-4 = Cannot allocate memory

We just took the dll from the files available on the mirror you 
mentioned an replace them step by step.


As requested by cfg the individual output from doing a cygcheck -s -v -r 
> cygcheck.out of each dll in use is attached:


1.5.18cygcheck.out
and
1.5.19cygcheck.out

Only the dll was replaced. No other changes.

Hope this will help the developers to troubleshoot.
Thanks so far for all your help and reply
And sorry again that our limited possibilities make it hard to 
troubleshoot the problem.

Hopefully we are now one step closer to a solution :-)
Thanks all for your understanding

Best Regards Dirk



Regards
Marco




__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 


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

  

Cygwin Configuration Diagnostics
Current System Time: Thu Sep 25 17:44:13 2008

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   D:\Other\cygwin\usr\local\bin
D:\Other\cygwin\bin
D:\Other\cygwin\bin
D:\Other\cygwin\usr\X11R6\bin
d:\winnt\system32
d:\winnt
d:\winnt\system32\wbem
c:\dos
c:\ntinst.ad
c:\utils
c:\detect
c:\net

Output from D:\Other\cygwin\bin\id.exe (nontsec)
UID: 500(Administrator) GID: 513(None)
0(root) 544(Administrators) 545(Users)

Output from D:\Other\cygwin\bin\id.exe (ntsec)
UID: 500(Administrator) GID: 513(None)
0(root) 544(Administrators) 545(Users)

SysDir: D:\WINNT\system32
WinDir: D:\WINNT

USER = `Administrator'
PWD = `/home/Administrator'
HOME = `/home/Administrator'
MAKE_MODE = `unix'

HOMEPATH = `\winnt\Profiles\Administrator'
MANPATH = `/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = `d:\winnt\Profiles\Administrator\Application Data'
HOSTNAME = `edd8r1p0'
APPSDIR = `d:\'
TERM = `cygwin'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 4, GenuineIntel'
WINDIR = `D:\WINNT'
OLDPWD = `/usr/bin'
USERDOMAIN = `EDD8R1P0'
OS = `Windows_NT'
ALLUSERSPROFILE = `d:\winnt\Profiles\All Users'
TEMP = `/cygdrive/d/winnt/Profiles/ADMINI~1/LOCALS~1/Temp'
COMMONPROGRAMFILES = `D:\Program Files\Common Files'
USERNAME = `Administrator'
PROCESSOR_LEVEL = `15'
FP_NO_HOST_CHECK = `NO'
SYSTEMDRIVE = `D:'
USERPROFILE = `d:\winnt\Profiles\Administrator'
CLIENTNAME = `Console'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = `\\EDD8R1P0'
PROCESSOR_ARCHITECTURE = `x86'
SHLVL = `1'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `d:'
!D: = `D:\Other\cygwin\bin'
PROMPT = `$P$G'
COMSPEC = `D:\WINNT\system32\cmd.exe'
TMP = `/cygdrive/d/winnt/Profiles/ADMINI~1/LOCALS~1/Temp'
SYSTEMROOT = `D:\WINNT'
PRINTER = `HP LaserJet 5'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0204'
INFOPATH = `/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = `D:\Program Files'
NUMBER_OF_PROCESSORS = `1'
SESSIONNAME = `Console'
COMPUTERNAME = `EDD8R1P0'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = 0x0022
  cygdrive prefix = `/cygdrive'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 0x000a
  native = `D:\Other\cygwin'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 0x000a
  native = `D:\Other\cygwin/bin'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 0x000a
  native = 

Cygwin 1.7 release

[Chris Love]

Hi all,
The feature set for version 1.7 looks very promising in terms of the IPV6 
support and the additional POSIX support.  What is a realistic timeframe to 
anticipate an official Cygwin 1.7 release?

Regards,

Chris



--
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: Problem to open big selfextracting Zip files from bash - starting from scratch :-)

[Buchbinder, Barry (NIH/NIAID) [E]]

Dirk Napierala wrote on Wednesday, September 24, 2008 12:51 PM:
>
> using other methods to launch the file (like unzip or cmd /c) is not
> an option due to company internals.

Can we assume that using the cygwin program cygstart.exe* is
also ruled out?  (*or maybe run.exe)

> Following the guideline "Changing Cygwin's Maximum Memory" from 
> http://cygwin.com/cygwin-ug-net/setup-maxmem.html
> the result of maxmem is
> $ ./maxmem.exe
> 5fffe000 bytes (1536.0Mb)
> (same result on a 2GB system as well as on a 4GB system) changing
> this by regtool -i set /HKLM/Software/Cygnus\
> Solutions/Cygwin/heap_chunk_in_mb 1024 or regtool -i set
> /HKLM/Software/Cygnus\ Solutions/Cygwin/heap_chunk_in_mb 1536
> followed by a reboot did not solve the issue.

I don't recall that you reported the results of setting this to
a very big number as suggested by Chris Faylor.  (Please excuse
me if you did and I missed it.)  For example:

$ regtool -i set /HKLM/Software/Cygnus\
Solutions/Cygwin/heap_chunk_in_mb 2048

You might also try 3072 and 4096.  And you might want to check
that your swap file can grow big enough to handle it.
  Control Panel
=> System
=> Advanced
=> Performance [Settings]
=> Advanced
=> Performance [Change]
=> Virtual memory [Change]

Good luck!

- Barry
  - Disclaimers:
- Statements made herein are not made on behalf of NIAID.
- Use any suggestion* I make at your own risk.
  (* e.g., playing with the swap file)

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

Продаем сайдинг производства USA, Canada, Russia

[Daniel Svetz]

ПР0ДАЖА И М0НТАЖ САЙДИНГА И В0Д0СТ0К0В.

- - -

Наша компания продает высококачественный виниловый и цокольный сайдинг
производства Канады, США и России.

ЦЕНЫ на материалы - значительно НИЖЕ рыночных, за счет прямых закупок
у экспортеров и специальных скидок предоставленных для нашей компании.

Выполняем доставку и монтаж любого вида сайдинга в кратчайшие сроки.
Выезжаем на замеры без выходных и задержек.
Наши менеджеры принимают звонки круглосуточно.
Цены на услуги монтажа Вас приятно удивят.

Работаем по схеме: Замер - Расчет - Доставка - Монтаж .

. . . .

Для более подробной информации, позвоните нашим менеджерам.

Телефоны менеджеров: 
 8 (926) 566-90-00

 8 <926>-021-08-47

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

dd, physical devices, Compact flash, Permission denied

[Krisitian Ivanov]

Hi,
 

I have a problem restoring a image back to a new CF card.

I am using the last Cygwin on Windows XP. 

I mounted the CF card :
 

mount -s -b //./I: /dev/cflash 

then

I made the image of the card:

dd if=/dev/cflash of=/home/flashcard.img

 

That worked without any problem, but

After that I have put a new formatted CF card

And I want to restore the image file that I made to the new one.
 

dd if=/home/flashcard.img of=/dev/cflash 

And it comes:

dd: opening '/dev/cflash': Permission denied

 

What is the problem?

Can you help me someone?
 

I want just to clone one CF card

 

Best Regards

Kristian Ivanov


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

dd, physical devices, Compact flash, Permission denied

[Krisitian Ivanov]

Hi,
 

I have a problem restoring a image back to a new CF card.

I am using the last Cygwin on Windows XP. 

I mounted the CF card :
 

mount -s -b //./I: /dev/cflash 

then

I made the image of the card:

dd if=/dev/cflash of=/home/flashcard.img

 

That worked without any problem, but

After that I have put a new formatted CF card

And I want to restore the image file that I made to the new one.
 

dd if=/home/flashcard.img of=/dev/cflash 

And it comes:

dd: opening '/dev/cflash': Permission denied

 

What is the problem?

Can you help me someone?
 

I want just to clone one CF card

 

Best Regards

Kristian Ivanov


--
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: dd, physical devices, Compact flash, Permission denied

[DePriest, Jason R.]

On Thu, Sep 25, 2008 at 8:45 PM, Krisitian Ivanov <> wrote:
> Hi,
>
>
> I have a problem restoring a image back to a new CF card.
>
> I am using the last Cygwin on Windows XP.
>
> I mounted the CF card :
>
>
> mount -s -b //./I: /dev/cflash
>


See if this helps: http://cygwin.com/cygwin-ug-net/using-specialnames.html

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

[SOLVED] RE: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[Dave Korn]

Charles Wilson wrote on 15 April 2008 00:07:

> Yaakov (Cygwin Ports) wrote:
>> Charles Wilson wrote:
>>> Changes sine libtool2.2-2.2.2-1
>>> =
>>> o changed base package name from 'libtool2.2' to 'libtool'
>>> o Added patches from Yaakov Selkowitz
>>>   http://cygwin.com/ml/cygwin/2008-04/msg00378.html
>> 
>> Do you know why I'm getting this:
>> 
>> *** Warning: linker path does not have real file for library -lwinmm.

   I do!

> I think that libtool hasn't been told that LDFLAGS should include
> -L/usr/lib/w32api.  

  Nope, because as we know that's always in the default search path.  It's
nowt t'do wi' t'PATH setting.

>> *** I have the capability to make that library automatically link in when
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libwinmm but no candidates were found. (...for file magic test)
>> 
>> Is it the /usr/lib/w32api location that libtool is having a hard time
>> with, the .a extension, or something else?
> 
> No, it's not a file type or identification problem; libtool can't find
> libwinmm.a at all.

  Yep, that's correct.  You ever-so-nearly had it here:

> FWIW:
> 
> $ ./func_win32_libid.sh /usr/lib/w32api/libwinmm.a
> x86 archive import
> 
> So that's ok.  (func_win32_libid.sh is just func_win32_libid() from
> libtool-2.2.2-2, with the OBJDUMP/NM/etc variables set.

  Spot the missing gap in the logic?

1.  This works.
2.  This is just func_win32_libid with some variables set.
3.  Therefore func_win32_libid works.

  Given that we know the conclusion is wrong, there must be a problem with the
antecedents.  #1 can't be wrong, we saw it with our own eyes.  So it must be
#2.

  Yep, you've got it.  The problem is that OBJDUMP is not set to anything, and
so the regexes all fail pretty hard.  And the reason that OBJDUMP is not set
to anything is due to this very common idiom in GNU projects that exercise
recursive makes:

# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
# friends when we are called from the top level Makefile.
AM_MAKEFLAGS = \
"AR_FLAGS=$(AR_FLAGS)" \
"CC_FOR_BUILD=$(CC_FOR_BUILD)" \
"CFLAGS=$(CFLAGS)" \
"CXXFLAGS=$(CXXFLAGS)" \
"CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
"CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
"INSTALL=$(INSTALL)" \
  ... snip ... actual list may vary per instance ...
"prefix=$(prefix)" \
"includedir=$(includedir)" \
"AR=$(AR)" \
"AS=$(AS)" \
"CC=$(CC)" \
"CXX=$(CXX)" \
"LD=$(LD)" \
"LIBCFLAGS=$(LIBCFLAGS)" \
"NM=$(NM)" \
"PICFLAG=$(PICFLAG)" \
"RANLIB=$(RANLIB)" \
"DESTDIR=$(DESTDIR)"


  Notice anything missing?  :-)  The answer is simple enough: add a couple of
lines that read:

"OBJDUMP=$(OBJDUMP)" \
"OBJDUMP_FOR_TARGET=$(OBJDUMP_FOR_TARGET)" \

somewhere in there (I put them after NM myself but it's of no functional
relevance) in the Makefile.am, regenerate the Makefile.in, and you're away.

  Chuck, it's not a libtool bug, but there might be something worth doing
upstream: since this happens a lot in GNU software, it might be a courtesy to
replace the reference to $OBJDUMP in func_win32_libid with something else
roughly along the lines of "${OBJDUMP:-echo 'Objdump not defined'; false}"
(which won't work as-is owing to the output redirections in place, but YKWIM:
something that emits an error and fails/bails).


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: dd, physical devices, Compact flash, Permission denied

[Christopher Faylor]

On Thu, Sep 25, 2008 at 08:51:40PM +0100, DePriest, Jason R. wrote:
>On Thu, Sep 25, 2008 at 8:45 PM, Krisitian Ivanov <> wrote:
>> Hi,
>>
>>
>> I have a problem restoring a image back to a new CF card.
>>
>> I am using the last Cygwin on Windows XP.
>>
>> I mounted the CF card :
>>
>>
>> mount -s -b //./I: /dev/cflash
>
>See if this helps: http://cygwin.com/cygwin-ug-net/using-specialnames.html

Mounting doesn't work that way on either Cygwin or Linux.

cgf

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

Question about cygwin-1.5.25-11 release notes

[Sean Daley]

I've got a quick question regarding one of the bullet points on the
release of cygwin-1.5.25-11.

- Fix a crash when creating stackdumps on Windows XP x64 Edition and
  Windows 2003 Server x64 Edition.

When it says crash, does that mean that the 2003x64 OS actually
crashes or a cygwin app will crash
on 2003x64?

Thanks.

Sean

--
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: montage: unable to read font...

[Gustavo Seabra]

Hi all,

I've sent this message to the cygwin list one week ago but, as I had
no response at all, I assume it didn't reach the list. So, I'm
reposting. I apologize if you got this before. I'd really appreciate
any help here.

Thanks,
Gustavo.

On Fri, Sep 19, 2008 at 3:27 PM, Gustavo Seabra
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have ImageMagick 6.4.0 installed here (in Cygwin). After the last
> upgrade, using setup.exe, I started getting the following messages
> anytime I run ImageMagick's 'montage':
>
> $ montage -label '%f' temp_??.png -geometry +5+5 -tile 3x3 -frame 5
> -shadow temp_page.png
> montage: unable to read font
> `/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.
> montage: unable to read font
> `/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.
> [...]
> $
>
> This error just repeats for every file being treated. In the end,
> montage does create the file, but the message is strange. I noticed
> that the same issue was mentioned once before here:
> http://sourceware.org/ml/cygwin/2008-04/msg00675.html
>
> but there are no answers to it. Could anybody suggest me a way to get
> rid of those messages? Thanks a lot.
>
> Gustavo.
> P.S.: I also include my cygchecck here.
>
> --
> Gustavo Seabra
> Postdoctoral Associate
> Quantum Theory Project - University of Florida
> Gainesville - Florida - USA


cygcheck.out
Description: x-unknown/gulp
--
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: libjack availability

[John Emmas]

Hi Yaakov,

Thanks for adding libjack to your SourceForge archive, here:-

http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/media/

Unfortunately, I can't figure out how to access it.  I tried running
cygwin's setup.exe, selecting "User URL" and adding the URL but this results
in an initialization error (cygwin cannot find the appropriate setup.ini
file).

Next I tried downloading the tarball that I found in the archive but it
seems to contain mostly documentation.

For libjack (which is what I'm interested in) the tarball contained a README
file with build instructions - the first of which is:-

unpack jack-audio-connection-kit-0.109.2-X-src.tar.bz2

However, that file doesn't seem to be in the archive and there's no
indication of how to obtain it.  Installing cygwin elements is usually very
simple so I feel that I must be missing something blatantly obvious.

Please can you (or anyone) let me have some instructions for extracting
libjack from the above archive?

Many thanks,

John 



--
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: montage: unable to read font...

[Marco Atzeri]

--- Gustavo Seabra  ha scritto:

> Hi all,
> 
> On Fri, Sep 19, 2008 at 3:27 PM, Gustavo Seabra
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I have ImageMagick 6.4.0 installed here (in
> Cygwin). After the last
> > upgrade, using setup.exe, I started getting the
> following messages
> > anytime I run ImageMagick's 'montage':
> >
> > $ montage -label '%f' temp_??.png -geometry +5+5
> -tile 3x3 -frame 5
> > -shadow temp_page.png
> > montage: unable to read font
> >
>
`/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.
> > montage: unable to read font
> >
>
`/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.
> > [...]
> > $


On the /usr/lib/ImageMagick-6.4.0/config/
the xml files report as directory where the font
should be:

/usr/share/fonts/corefonts/

but this directory does not exist.

workaround

$ cd /usr/share
$ mkdir fonts
$ cd fonts
$ ln -s /cygdrive/c/WINDOWS/Fonts corefonts

so now 
/usr/share/fonts/corefonts

will link to 
/cygdrive/c/WINDOWS/Fonts

where the TTF font of windows are.

Regards
Marco


__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

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