Re: [ANNOUNCEMENT] Updated: sed-4.1.5-2

[Corinna Vinschen]

On Aug  2 11:05, Joachim Achtzehnter wrote:
> Hi Corinna,
> 
> You wrote:
> 
> >I've updated the version of sed to 4.1.5-2.
> >
> >It reverts the default behaviour of sed back to treating CR/LF as
> >lineendings, in contrast to 4.1.5-1, which only treated the trailing LF
> >as lineending and the preceeding CR as the last character on the line.
> 
> Thank you very much for this fix. It will make life easier for all of us 
> who struggle with a mix of native and Cygwin tools. It is very much 
> appreciated that as far as line endings are concerned the attitude taken by 
> Cygwin developers is not "use POSIX line endings".

Sorry, but that's not why I did it.  My personal opinion is still
strongly on the "use POSIX line endings" side.  I made the fix only so
that other mailing lists don't suffer (see the latest discussion on the
binutils mailing list.  Other than that I have only so much patience for
the dreaded textmode/binmode problem and I'm seriously contemplating
(for years) to just remove textmode from Cygwin.  CRLF lineendings are
in the top 10 of the worst ideas in the OS business.

> At the risk of provoking another salvo of emotional responses I'd like to 
> express the hope that those who take the opposite attitude with respect to 
> path names ("use POSIX paths") may reconsider their position. I would 

Not me.


Corinna

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

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

Re: cygwin copy problems usb 2.0

[Reini Urban]

Christopher Faylor schrieb:

On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote:

Christopher Faylor schrieb:

On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:

On Jul 27 13:48, aldana wrote:

isn't there a possibitly that cygwin provides a quicker
cp-implementation?  i mean 4 minutes for a copy of 70MB to a memstick
(instead of CopyFile() 20 sec.) is not really good performance.  i
guess there is a reason for that...

Right, how did you know?  The reason is that cp is a portable
implementation using simple reads and writes to perform the copy.
There's no such thing as a CopyFile routine on POSIX systems.

A few weeks ago there was a guy in libc-alpha mailing list complaining
that glibc's API wasn't as rich and powerful as what is found on Windows.

...
I'm really seeing the non-optimized cygwin cp behaviour causing bad 
reputation, which could be easily patched and maybe even accepted 
upstream. Who knows. Eric what do think? Would it be worthful to think 
about?


If this is what you want then you should look into a non-cygwin
solution.  There are a couple of projects which provide GNU tools for
Windows without resorting to something like the Cygwin DLL.


It's not for me, I know how to call copy or xcopy or how to install 
mingw's cp, which doesn't help btw.

It's for the project reputation. Think of buildtimes.


Also, don't you see something wrong with the mindset of "Windows Fast.
Cygwin Slow.  So, must use straight Windows functions." without even
bothering to do any research into what is causing the slowness?  


I didn't say that and I see the same problem as you.


How do you, or anyone who cares about this know that this "problem", know that
it isn't correctable without resorting to patching cp?


I have no idea, but it should be investigated. If it's just the buffer 
size or some waits in the driver communication.


We need not to optimize away every POSIX utility with Windows API's.
But for cp vs CopyFile would make sense. If we are on Windows supported 
Filesystems, which costs nothing to get known (we have no mount calling 
fs-drivers yet), why not call CopyFile() for files bigger than the 
buffer size? Small files would gain nothing because of the cost of path 
conversion.
But it's really up to the coreutils maintainer or some of us to come up 
with a patch.

--
Reini

--
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: Help with cygports

[Reini Urban]

Maurício schrieb:
  Cygports documentation says I should put a copy of setup.hint and 
README inside CYGWIN-PATCHES directory. Where is that directory supposed 
to be?


Under your source directory.

This is really a basic package maintainer question answered at the 
cygwin website.

http://cygwin.com/setup.html#package_contents
--
Reini Urban

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

1.5.21-1 missing header file 'jpeglib'

[Susana Manrique de Lara Sanz]

Hi everybody,

I've installed Cygwin about 5 times because the "jpeglib.h" seems to be 
missing.
I install it from the internet and select all the packages needed. IN libs 
section I need libjpeg62, libpng12-devel, zlib, which all seem to be 
installed properly except from the first one.


I say this becasuse when I try to compile my project this message is shown:
missing header file 'jpeglib.h'
I've search for it and I can't find it anywhere, I thought it should be at 
/cygwin/usr/include/ as the other libs are but the libjpeg isn't there.


I've tried to reinstall the library from the setup.exe and also using 
different mirrors but nothing has changed.
The package has been downloaded but the setup process seem t forget to 
install it or something.
Should I just untar the downloaded package to the /cygwin/usr/include/ 
directory? if that's the correct directory to do that, which I'm not sure at 
all.

I'm new at cygwin and I don't know muach about unix like systems...

Thak you for your attention,

Susana



--
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: NTFS fragmentation

[Dave Korn]

On 03 August 2006 00:46, Vladimir Dergachev wrote:


Hi Vladimir,


>>> Please CC me - I am not on the list.

  Done :)

> 
> PS I'll try writing a C program when time permits - any suggestions on what
> API besides regular open/write/close to use ?

  I think you might want to go straight to ZwCreateFile in the native API, and
see if you can pin the difference in behaviour down to some change in the
flags passed to that call.

  Actually, maybe the most informative thing would be to look at the device IO
controls sent by both testcases, using filemon or similar.


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: NTFS fragmentation

[Christian Franke]

Vladimir Dergachev wrote:

...
Also, I tried the following experiment - found a 17 MB file in ibiblio.org and 
downloaded it with FireFox. The file ended up fragmented into more than 200 
pieces. Tried the same file with IE - no fragmentation.
  


The difference is probably that IE initially creates the file with full 
size and then overwrites it. This is at least the case if you copy files 
with explorer, copy, xcopy or CopyFileEx().


FireFox, Cygwin's cp and most other programs use regular sequential 
write. This may lead to fragmentation when the disk has less space.


Christian


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

This is the end. Goodbye.

[Len Rose]

netsys.com is under new ownership, and I have left for
some dark skies in the mountains of New Mexico.

This email address is no longer valid. If you know
me you have my current email address., Otherwise, use
my phone number. Goodbye from Len Rose <[EMAIL PROTECTED]>

PS (in case you don't know..this is an automatic responder)

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

Re: 1.5.20(0.156/4/2) pipe hangs, dos files

[Lev Bishop]

On 8/2/06, Darryl Mile:

Okay you seem to have some understanding as to how and why it failed for
the "unison" group of users.  Do you think the commented out code is
fixable in any so that all cases work correctly ?


Iff you can come up with a way to distinguish the two situations: 1)
blocking read is in progress. 2) no blocking read is in progress. I
can't come up with a way of doing that which is reliable in all cases
of multiple readers on the same pipe, multiple writers on the same
pipe, non-cygwin windows native processes involved, etc. Worse, I
can't even come up with a way that helps the more common cases (single
reader, single writer, both cygwin processes) and falls  back to the
current behaviour for the other cases. Instead, everything I've tried
would deadlock in those less common cases.

There probably is a way to do it, but enough people have spent enough
time pondering this at this point, that you can be assured it isn't
something immediately obvious.

Anyway, at this point, if you can code something up and show that it
works, then that's more likely to impress the maintainers than further
talking. (And even if the maintainers don't accept the patch, if it
fixes the problem for you, then there's nothing stopping you from
using your own patch for your own purposes, and even distributing it
to anyone else who finds it useful. That's the nice thing about the
GPL).

Lev

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

Re: 1.5.21-1 missing header file 'jpeglib'

[Igor Peshansky]

On Thu, 3 Aug 2006, Susana Manrique de Lara Sanz wrote:

> Hi everybody,

Hi, Susana,

> I've installed Cygwin about 5 times because the "jpeglib.h" seems to be
> missing.

We don't know what packages you've installed, so can't say if this is a
problem with your installation or a more general one.  Please read and
follow the Cygwin problem reporting guidelines at
, particularly the part about attaching
the output of "cygcheck -svr" (as an uncompressed text *attachment*).

> I install it from the internet and select all the packages needed. IN
> libs section I need libjpeg62, libpng12-devel, zlib, which all seem to
> be installed properly except from the first one.

What makes you believe that?  The contents of the libjpeg62 is a single
DLL, /usr/bin/cygjpeg-62.dll (which, BTW, is a compatibility DLL -- you
should be installing libjpeg6b for a more current one).  However, if you
select the right packages, libjpeg6b should be selected automatically for
you.

> I say this becasuse when I try to compile my project this message is
> shown: missing header file 'jpeglib.h'
> I've search for it and I can't find it anywhere, I thought it should be
> at /cygwin/usr/include/ as the other libs are but the libjpeg isn't
> there.

It's not a lib, it's an include file.  But yes, it's supposed to be under
/usr/include once you've installed the right packages.

> I've tried to reinstall the library from the setup.exe and also using
> different mirrors but nothing has changed.

Because you're reinstalling the wrong library.  Try "cygcheck -l
libjpeg62" to see the contents of that package on your system.

> The package has been downloaded but the setup process seem t forget to
> install it or something.
> Should I just untar the downloaded package to the /cygwin/usr/include/
> directory? if that's the correct directory to do that, which I'm not
> sure at all.

I doubt that setup "forgets" to install any package that was selected by
the user.  Try searching for the file you need on the Cygwin package
search page at , and then install that
package using setup.

> I'm new at cygwin and I don't know muach about unix like systems...

Plenty to learn, then... :-)
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

It's hard to find a black cat in a dark room, especially if it's not there
to begin with.  --Confucius

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

Re: 1.5.20(0.156/4/2) pipe hangs, dos files

[Brian Ford]

On Thu, 3 Aug 2006, Darryl Miles wrote:
> Brian Ford wrote:
> > Doesn't this explain the problem nicely?
> >
> > http://www.cygwin.com//ml/cygwin-patches/2004-q4/msg00018.html
>
> Yes that casts light on the problem.  Did you get around to trying to
> reverse the direction of the data flow through the pipe or any other
> similar testing to form a conclusion ?

No, I (and IIRC, the Cygwin community)  didn't.  I don't know if the OP
did or not as he seemed to dissapear shortly after that.

It hasn't been a priority for me or my company, so I haven't looked into
it.  I just have a good memory for finding these things in the archives
;-).

> The problem here is that I am a Unix person,

Same here.

> this is the principal reason why CYGWIN appeals to me.  So I really dont
> have the motivation to "investigate" the matter and hunt down
> undocumented platform quirks.
>   The FILE_PIPE_LOCAL_INFORMATION is also an undocumented use of
> NtQueryInformationFile.

Yes, I remember that in the discussion.

> I do have the energy to work on my proposal to implement until
> completion but even that it a little mared by the possibility of having
> such a patch rejected by the committers.

Been there, done that ;-).

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...



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

Re: 1.5.21-1 missing header file 'jpeglib'

[Susana Manrique de Lara Sanz]

We don't know what packages you've installed, so can't say if this is a
problem with your installation or a more general one.


I've install the default packages plus this ones:
Devel -> make, gcc-g++, cvs, gdb, libxml2-devel, patchutils
Net -> rsync, openssh
Text -> util-linux
Libs -> libjpeg62, libpng12-devel, zlib


Please read and follow the Cygwin problem reporting guidelines at
, particularly the part about attaching
the output of "cygcheck -svr" (as an uncompressed text *attachment*).


Ok, so there it is the file with the output of cygcheck.


I install it from the internet and select all the packages needed. IN
libs section I need libjpeg62, libpng12-devel, zlib, which all seem to
be installed properly except from the first one.


What makes you believe that?  The contents of the libjpeg62 is a single
DLL, /usr/bin/cygjpeg-62.dll (which, BTW, is a compatibility DLL -- you
should be installing libjpeg6b for a more current one).  However, if you
select the right packages, libjpeg6b should be selected automatically for
you.

Try "cygcheck -l libjpeg62" to see the contents of that package on your 
system.


I did it:
$ cygcheck -l libjpeg62
/usr/bin/cygjpeg-62.dll


I doubt that setup "forgets" to install any package that was selected by
the user.  Try searching for the file you need on the Cygwin package
search page at , and then install that
package using setup.


Well, but the file I need is in the package I've already installed, the 
libjpeg62, that as you said, by selecting it the libjpeg6b is also selected 
to be installed.



Plenty to learn, then... :-)


yeah, now I wish I've learnt it before but it's never too late huh? ^_^


Cygwin Configuration Diagnostics
Current System Time: Thu Aug 03 15:51:28 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   D:\cygwin\usr\local\bin
   D:\cygwin\bin
   D:\cygwin\bin
   D:\cygwin\usr\X11R6\bin
   d:\ARCHIV~1\Borland\CBUILD~1\Bin
   d:\ARCHIV~1\Borland\CBUILD~1\Projects\Bpl
   c:\WINDOWS\system32
   c:\WINDOWS
   c:\WINDOWS\System32\Wbem
   c:\Archivos de programa\ATI Technologies\ATI Control Panel
   c:\Archivos de programa\UltraEdit
   c:\Archivos de programa\Microsoft SQL Server\90\Tools\binn\
   c:\Archivos de programa\Java\jdk1.5.0_07\bin

Output from D:\cygwin\bin\id.exe (nontsec)
UID: 1003(Susi)  GID: 513(Ninguno)
0(root)  513(Ninguno) 544(Administradores)
545(Usuarios)1007(ORA_DBA)

Output from D:\cygwin\bin\id.exe (ntsec)
UID: 1003(Susi)  GID: 513(Ninguno)
0(root)  513(Ninguno) 544(Administradores)
545(Usuarios)1007(ORA_DBA)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'Susi'
PWD = '/home/Susi'
CYGWIN = 'server'
HOME = '/home/Susi'
MAKE_MODE = 'unix'

HOMEPATH = '\Documents and Settings\Susi'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\Susi\Datos de programa'
HOSTNAME = 'portatil'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 36 Stepping 2, AuthenticAMD'
WINDIR = 'C:\WINDOWS'
VS80COMNTOOLS = 'C:\Archivos de programa\Microsoft Visual Studio 
8\Common7\Tools\'

OLDPWD = '/usr/bin'
USERDOMAIN = 'PORTATIL'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/Susi/CONFIG~1/Temp'
COMMONPROGRAMFILES = 'C:\Archivos de programa\Archivos comunes'
USERNAME = 'Susi'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Documents and Settings\Susi'
CLIENTNAME = 'Console'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\PORTATIL'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\Documents and Settings\Susi\Escritorio'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
!D: = 'D:\cygwin\bin'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOCUME~1/Susi/CONFIG~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = '\\BIZKIT\hp psc 1200 series'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '2402'
CLASSPATH = '.'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Archivos de programa'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'Console'
JAVAPATH = 'C:\Archivos de programa\Java\jdk1.5.0_07'
COMPUTERNAME = 'PORTATIL'
_ = '/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) = '/cygdrive'
 cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
 (default) = 'D:\cygwin'
 flags = 0x000a
HKEY_LOCAL_MA

Re: 1.5.21-1 missing header file 'jpeglib'

[Igor Peshansky]

On Thu, 3 Aug 2006, Susana Manrique de Lara Sanz wrote:


> We don't know what packages you've installed, so can't say if this is
> a problem with your installation or a more general one.

I've install the default packages plus this ones:
Devel -> make, gcc-g++, cvs, gdb, libxml2-devel, patchutils
Net -> rsync, openssh
Text -> util-linux
Libs -> libjpeg62, libpng12-devel, zlib


Right -- all of this is in your cygcheck output.


> Please read and follow the Cygwin problem reporting guidelines at
> , particularly the part about
> attaching the output of "cygcheck -svr" (as an uncompressed text
> *attachment*).

Ok, so there it is the file with the output of cygcheck.


Thanks.


> > I install it from the internet and select all the packages needed.
> > IN libs section I need libjpeg62, libpng12-devel, zlib, which all
> > seem to be installed properly except from the first one.
>
> What makes you believe that?  The contents of the libjpeg62 is a
> single DLL, /usr/bin/cygjpeg-62.dll (which, BTW, is a compatibility
> DLL -- you should be installing libjpeg6b for a more current one).
> However, if you select the right packages, libjpeg6b should be
> selected automatically for you.
>
> Try "cygcheck -l libjpeg62" to see the contents of that package on
> your system.

I did it:
$ cygcheck -l libjpeg62
/usr/bin/cygjpeg-62.dll


Right.  So why would you expect to find the include file there as well?


> I doubt that setup "forgets" to install any package that was selected
> by the user.  Try searching for the file you need on the Cygwin
> package search page at , and then install
> that package using setup.

Well, but the file I need is in the package I've already installed, the
libjpeg62, that as you said, by selecting it the libjpeg6b is also
selected to be installed.


Why do you think the file you need is in libjpeg62?  The only file in that
package is /usr/bin/cygjpeg-62.dll, which is what "cygcheck -l" shows you.


> Plenty to learn, then... :-)

yeah, now I wish I've learnt it before but it's never too late huh? ^_^


Nope, never too late.  Try searching for the needed file (jpeglib.h) again
on the package search page (), and install
the package that actually contains it (according to your cygcheck output,
you don't have it installed yet).
Igor
--
http://cs.nyu.edu/~pechtcha/
 |\  _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
|,4-  ) )-,_. ,\ (  `'-'old name: Igor Pechtchanski
   '---''(_/--'  `-'\_) fL  a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

RE: 1.5.21-1 missing header file 'jpeglib'

[Dave Korn]

On 03 August 2006 09:55, Susana Manrique de Lara Sanz wrote:

> I've installed Cygwin about 5 times because the "jpeglib.h" seems to be
> missing.
> I install it from the internet and select all the packages needed. IN libs
> section I need libjpeg62, libpng12-devel, zlib, which all seem to be
> installed properly except from the first one.
>
> I say this becasuse when I try to compile my project this message is shown:
> missing header file 'jpeglib.h'
> I've search for it and I can't find it anywhere, I thought it should be at
> /cygwin/usr/include/ as the other libs are but the libjpeg isn't there.

  None of those packages include jpeglib.h.  To find out what cygwin package
contains any particular file, go to http://cygwin.com/packages/ and enter it
into the search box - you'll get to 
http://cygwin.com/cgi-bin2/package-grep.cgi?grep=jpeglib.h
which shows you that the package you want is called jpeg and it's currently at
version jpeg6b-11.  The libjpeg62 that you installed only contains the runtime
dll; what you need is the development package with the link libraries and
headers.

> The package has been downloaded but the setup process seem t forget to
> install it or something.
> Should I just untar the downloaded package to the /cygwin/usr/include/
> directory? if that's the correct directory to do that, which I'm not sure at
> all.

  This isn't what's happened, but if setup had forgotten something, the
correct thing to do would be to re-run it and re-select the package for
install from local directory.

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: Behaviour that I don't understand

[Alan Chandler]

Paul Slootman writes: 

On Wed 02 Aug 2006, Alan Chandler wrote: 

The /etc/rsyncd.conf file has the following in it  

chroot = false 
strict modes = false
hosts allow = 192.168.0.0/24 127.0.0.1 


[system]
path = /cygdrive/c
comment = the complete c drive 



[alan]
path = /cygdrive/c/Documents and Settings/ChandlerA
comment = Alan's specific user space
[...] 

HOWEVER 

If I try to list the contents of either module from local host (thus) 

rsync localhost::system 

it works, but if I list the contents via 


rsync rabbit::system
(either remotely or locally) 

then I get  


@ERROR: access denied to system from roo.home (192.168.0.20)


Try putting the hosts allow line in the modules definition; the man page
does say:
You may also include any module parameters in the global  part  of  the
config  file in which case the supplied value will override the default
for that parameter.
However maybe there's some bug :-)


Its a bit hard because I am at work rather than home, so not with the same 
IP addresses.  Nevertheless I can simulate the effect by setting the work IP 
address in rsyncd.conf and connecting from the same machine. 


Moving the hosts allow into the module does not effect things EXCEPT that
I didn't include localhost in my host allow statements, but that still 
works. 



BTW: you don't mention what version you're using.


Its 2.6.6 (Protocol 29) under cygwin for the machine running the daemon 

I am using itself as one client (test above), and when at home I am running 
from Debian Sarge - which is 2.6.4 (Protocol 29). 

I DO now have a work around that works - ie list the individual IP addresses 
of the machines I want to allow to connect, rather than a range 

ie 

hosts allow = 192.168.0.20 192.168.0.21 

rather than 

hosts allow = 192.168.0.0/24 

The second form DOES seems to work on my other machines (all under linux as 
opposed to this machine using cygwin) AND I had the exact same configuration 
working on my old laptop (running Windows 2000 professional) which just 
stopped working when I got a new work laptop with Windows XP and I 
transfered the configuration across. When I first raised this I hadn't 
narrowed the problem down enough to find a work around - so I was looking 
for answers.  Now I suspect some bug with the cygwin implementation, and I 
would just like to help out to see that it can get fixed if that is indeed 
the case, or understand what I am doing wrong if it is not. 





--
Alan Chandler
[EMAIL PROTECTED] 



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

Re: cygwin copy problems usb 2.0

[Christopher Faylor]

On Thu, Aug 03, 2006 at 09:54:13AM +0200, Reini Urban wrote:
>Christopher Faylor schrieb:
>>On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote:
>>>Christopher Faylor schrieb:
On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
>On Jul 27 13:48, aldana wrote:
>>isn't there a possibitly that cygwin provides a quicker
>>cp-implementation?  i mean 4 minutes for a copy of 70MB to a memstick
>>(instead of CopyFile() 20 sec.) is not really good performance.  i
>>guess there is a reason for that...
>Right, how did you know?  The reason is that cp is a portable
>implementation using simple reads and writes to perform the copy.
>There's no such thing as a CopyFile routine on POSIX systems.
A few weeks ago there was a guy in libc-alpha mailing list complaining
that glibc's API wasn't as rich and powerful as what is found on Windows.
>...
>>>I'm really seeing the non-optimized cygwin cp behaviour causing bad 
>>>reputation, which could be easily patched and maybe even accepted 
>>>upstream. Who knows. Eric what do think? Would it be worthful to think 
>>>about?
>>
>>If this is what you want then you should look into a non-cygwin
>>solution.  There are a couple of projects which provide GNU tools for
>>Windows without resorting to something like the Cygwin DLL.
>
>It's not for me, I know how to call copy or xcopy or how to install 
>mingw's cp, which doesn't help btw.
>It's for the project reputation. Think of buildtimes.

That logic could be used for bash, too.   Maybe Eric should spend a few
months modifying bash to avoid fork and use CreateProcess.  I'm sure it
would be faster.  It's a slippery slope and I really don't want to start
down that path for Cygwin.

>>Also, don't you see something wrong with the mindset of "Windows Fast.
>>Cygwin Slow.  So, must use straight Windows functions." without even
>>bothering to do any research into what is causing the slowness?  
>
>I didn't say that and I see the same problem as you.

No.  You don't.  You see a problem that would be solved by someone
modifying cp to use the Win32 API.

>>How do you, or anyone who cares about this know that this "problem",
>>know that it isn't correctable without resorting to patching cp?
>
>I have no idea, but it should be investigated.  If it's just the buffer
>size or some waits in the driver communication.

So, as usual in an open source project, if it bothers you that much then
investigate it.

>But it's really up to the coreutils maintainer or some of us to come up 
>with a patch.

I would submit that if one of the project leaders thinks it is a
terrible idea, then the packae maintainer should seriously take that
into consideration.

Again, if this problem is really important to someone then maybe they
should take time to understand what is causing the slowness before
suggesting solutions.

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/

Is casting away const OK for cygwin's execvp

[Volker Quetschke]

Hi

I encountered this when writing some c++ program that uses execvp
to start another process.

Basically (see the attached example program)

  int execvp(const char *path, char * const *argv);

the prototype of execvp() doesn't like constant char arrays for the second
parameter, but that's what you get when you use the c_str() function
on strings.

Googling for this problem didn't help beside the point that it, depending
on the implementation, is save on some architectures to "cast away"
the const because the parameters are copied by execvp and therefore the
new process cannot change them in its parent.

Is it save with g++ on cygwin to to this?

   execvp(nargv[0], const_cast(nargv) )
^^

(Yes, I know that I can just copy the const char* into new char*
arrays but this includes extra memory and overhead and the parameter
lists of the application where the code comes from can get rather long
and the program is called very often so that I would like to avoid that.)

I would appreciate some insight here.


   Volker

-- 
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D



signature.asc
Description: OpenPGP digital signature

Re: Is casting away const OK for cygwin's execvp

[Volker Quetschke]

Volker Quetschke wrote:
> Basically (see the attached example program)

D'oh! I forgot the attachment.

  Volker

-- 
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
#include 
#include 
#include 
#include 

using std::string;
using std::size_t;

int main() {

  const char *nargv[3];

  string arg1("echo");
  nargv[0] = arg1.c_str();

  string arg2("test");
  nargv[1] = arg2.c_str();

  nargv[2] = NULL;

  // Unfortunately the prototype of execvp does not like const char*,
  // actually not const char* nargv[] coming from .c_str(). So either
  // we copy everything into newly allocated variables or we force it
  // with a cast. const_cast() - Is this OK?
  if ( execvp(nargv[0], const_cast(nargv) ) < 0 ) {
perror("Execvp error.  Aborting.");
exit(1);   
  }
  return 1;
}


signature.asc
Description: OpenPGP digital signature

GnuPG bug: --refresh-keys

[Max Bowsher]

When running 'gpg --refresh-keys', the second updated key results in:

gpg: renaming `/home/max/.gnupg/pubring.gpg' to
`/home/max/.gnupg/pubring.gpg~' failed: Permission denied
gpg: error writing keyring `/home/max/.gnupg/pubring.gpg': file rename error
gpg: key : "" 28 new signatures
gpg: error reading `[stream]': file rename error


Given that:
 * this happens for the *second* updated key

 * having another process running at the same time, rapidly moving away
any new pubring.gpg~ files avoids the error

 * it is presumably Cygwin-specific

it seems extremely likely that gnupg has a file descriptor leak, such
that when the second key is processed, gnupg still has an open file
descriptor on the file pubring.gpg~ when it attempts to overwrite it by
renaming another file onto that name. Windows then objects.

Max.



signature.asc
Description: OpenPGP digital signature

Re: Bug in cygcheck 1.90

[Corinna Vinschen]

On Aug  2 17:09, Andr? Bleau wrote:
> There is a bug in cygcheck 1.90 (included in Cygwin package 
> 1.5.21(0.156/4/2) 2006-07-30):
> 
> $ uname -a
> CYGWIN_NT-5.0 ableau 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin
> 
> $ cygcheck -V
> cygcheck version 1.90
> System Checker for Cygwin
> Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Red Hat, Inc.
> Compiled on Jul 30 2006
> 
> Example o fthe bug:
> 
> $ cygcheck C:\\WINNT\\system32\\COMDLG32.DLL
> C:/WINNT/system32/COMDLG32.DLL
>  C:/WINNT/system32\SHLWAPI.DLL
> [...]

Thanks for the report, I've checked in a patch to cvs.


Corinna

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

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

ctype.h extra paren in latest source

[Tom Woodfin]

In trying to build out of the latest CVS sources, I noticed that a 
spurious paren seems to have been added to mingw/include/ctype.h in rev 
1.10:


http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/ctype.h.diff?r1=1.9&r2=1.10&cvsroot=src&f=h 



See line 146.

This caused a compilation error in gcc. Removing the paren resolved the 
issue.


Thanks,
~Tom Woodfin


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

Re: cygwin copy problems usb 2.0

[Corinna Vinschen]

On Aug  3 01:54, Eric Blake wrote:
> > >I'm really seeing the non-optimized cygwin cp behaviour causing bad 
> > >reputation, which could be easily patched and maybe even accepted 
> > >upstream. Who knows. Eric what do think? Would it be worthful to think 
> > >about?
> 
> I don't really want to maintain a Windows API patch, and doubt that

Good.

> it would be accepted upstream.  Now if there were something more
> POSIX-y that we could do to speed things up, such as posix_fadvise,

posix_fadvise can't be implemented nicely, AFAICS.  The POSIX semantics
require an already opened file and the advice is given for an offset and
a length.  The Windows semantics only allow to give the advice for the
whole file, and only switching between FILE_SEQUENTIAL_ONLY or "normal",
using ZwSetInformationFile.  By re-opening the file using ZwOpenFile it
would also be possible to toggle the FILE_RANDOM_ACCESS flag.  Still,
it's always for the whole file, not for an area giving offset and length.


Corinna

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

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

Re: cygwin copy problems usb 2.0

[Igor Peshansky]

On Thu, 3 Aug 2006, Corinna Vinschen wrote:

> On Aug  3 01:54, Eric Blake wrote:
> > > >I'm really seeing the non-optimized cygwin cp behaviour causing bad
> > > >reputation, which could be easily patched and maybe even accepted
> > > >upstream. Who knows. Eric what do think? Would it be worthful to think
> > > >about?
> >
> > I don't really want to maintain a Windows API patch, and doubt that
>
> Good.
>
> > it would be accepted upstream.  Now if there were something more
> > POSIX-y that we could do to speed things up, such as posix_fadvise,
>
> posix_fadvise can't be implemented nicely, AFAICS.  The POSIX semantics
> require an already opened file and the advice is given for an offset and
> a length.  The Windows semantics only allow to give the advice for the
> whole file, and only switching between FILE_SEQUENTIAL_ONLY or "normal",
> using ZwSetInformationFile.  By re-opening the file using ZwOpenFile it
> would also be possible to toggle the FILE_RANDOM_ACCESS flag.  Still,
> it's always for the whole file, not for an area giving offset and length.

Theoretically, it's possible to implement posix_fadvise only for offset=0
and length=, and have it fail with EINVAL otherwise...
While technically not POSIX-compliant, it would still allow for better
implementation of things like copy...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Make command error in Cygwin

[banjanap]

Hi all,
I am trying to run Httperf tool in Cygwin. The Cygwin and httperf 
are both installed on saperate drives on my syteam running win2000 the 
steps involved in running httperf in cygwin are 

making a build directory and the navigatinig to the build directory and 
configuring the tool from the build directory and finally issuing a 
make command from the build directory. However I am stuck in the final 
step whenever I issue a make command I get the following error:

/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:83: warning: no 
semicolon at end of struct or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:84: warning: type 
defaults to `int' in declaration of `reply_bytes_received'
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:84: warning: data 
definition has no type or storage class
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:85: error: parse 
error before "footer_bytes_received"
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:85: warning: type 
defaults to `int' in declaration of `footer_bytes_received'
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:85: warning: data 
definition
 has no type or storage class
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:88: error: parse 
error before '}' token
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:89: warning: type 
defaults to `int' in declaration of `basic'
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:89: warning: data 
definition
 has no type or storage class
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`perf_sample':
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:107: error: request 
for memb
er `reply_rate_sum' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:108: error: request 
for member `reply_rate_sum2' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:109: error: request 
for memb
er `reply_rate_min' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:110: error: request 
for member `reply_rate_min' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:111: error: request 
for member `reply_rate_max' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:112: error: request 
for member `reply_rate_max' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:113: error: request 
for member `num_reply_rates' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`conn_timeout':

/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:124: error: request 
for member `num_client_timeouts' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`conn_fail':
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:140: error: request 
for member `num_sock_fdunavail' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:141: error: request 
for member `num_sock_ftabfull' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:142: error: request 
for member `num_sock_refused' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:143: error: request 
for member `num_sock_timeouts' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:147: error: request 
for member `num_sock_reset' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:157: error: request 
for member `num_other_errors' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`conn_created':

/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:166: error: request 
for member `max_conns' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:167: error: request 
for member `max_conns' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`conn_connecting':
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:178: error: request 
for member `num_conns_issued' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`conn_connected':
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:188: error: request 
for member `conn_connect_sum' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:189: error: request 
for member `num_connects' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c: In function 
`conn_destroyed':
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:205: error: request 
for member `conn_lifetime_sum' in something not a structure or union
/cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:206: error: request 
for member `conn_lifetime_sum2' in something not a st

memory problems with cvs gnu emacs on latest cygwin

[emacs user]

I have reported this problem to the gnu emacs developers a few times, but it 
seems that emacs is not actively maintained for cygwin right now.  perhaps 
someone here can help?  I am happy to provide more details if needed.   
thanks...


A brief problem description:

memory usage of emacs does not decrease after killing buffers with images.

details:

I start emacs with

emacs.exe -q --no-site-file&

the memory usage right after startup is 14912;

after editing a small image: 16452;

after killing the buffer with the image and using M-:(clear-image-cache 
t)RET: 16476;


after editing a large image: 39164;

again quit+clear cache: 34484;

edit small+medium+large images: 58936;

quit+clear: 87636...  (increased!)

I hope someone can look into this, and I am happy to provide information 
given specific instructions.


thanks...  EU


In GNU Emacs 22.0.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
of 2006-07-31 on cata2
X server distributor `The Cygwin/X Project', version 11.0.60899901
Important settings:
 value of $LC_ALL: nil
 value of $LC_COLLATE: C
 value of $LC_CTYPE: nil
 value of $LC_MESSAGES: nil
 value of $LC_MONETARY: nil
 value of $LC_NUMERIC: nil
 value of $LC_TIME: nil
 value of $LANG: nil
 locale-coding-system: nil
 default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
 tooltip-mode: t
 tool-bar-mode: t
 mouse-wheel-mode: t
 menu-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 blink-cursor-mode: t
 unify-8859-on-encoding-mode: t
 utf-translate-cjk-mode: t
 auto-compression-mode: t
 line-number-mode: t

Recent input:



 

Recent messages:
(/usr/local/emacs/src/emacs -q --no-site-file)
For information about the GNU Project and its goals, type C-h C-p.
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done

_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/



--
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: NTFS fragmentation

[Vladimir Dergachev]

On Thursday 03 August 2006 5:18 am, Dave Korn wrote:
> On 03 August 2006 00:46, Vladimir Dergachev wrote:
>
>
> Hi Vladimir,
>
> >>> Please CC me - I am not on the list.
>
>   Done :)
>

>   Actually, maybe the most informative thing would be to look at the device
> IO controls sent by both testcases, using filemon or similar.

Thank you for the suggestion !

I used filemon and discovered that all three programs (ntfs_test.tcl, Firefox 
and IE) use sequential access, but IE writes the file first to Temporary 
Internet Files folder and then copies it.

If one runs analyze from defragmenter while IE is still downloading the file 
the file in the Temporary Internet Files folder is just as fragmented as 
other files.

I guess this means that sequential writes are officially broken on NTFS.

Anyone has any idea for a workaround ? It would be nice if a simple
tar zcvf a.tgz * does not result in a completely fragmented file.

  thank you

  Vladimir Dergachev

>
>
> 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: NTFS fragmentation

[Vladimir Dergachev]

On Thursday 03 August 2006 5:35 am, Christian Franke wrote:
> Vladimir Dergachev wrote:
> > ...
> > Also, I tried the following experiment - found a 17 MB file in
> > ibiblio.org and downloaded it with FireFox. The file ended up fragmented
> > into more than 200 pieces. Tried the same file with IE - no
> > fragmentation.
>
> The difference is probably that IE initially creates the file with full
> size and then overwrites it. This is at least the case if you copy files
> with explorer, copy, xcopy or CopyFileEx().
>
> FireFox, Cygwin's cp and most other programs use regular sequential
> write. This may lead to fragmentation when the disk has less space.

Well, what I see is that the file is completely fragmented on a 400 GB disk, 
which is 40% full and has been recently defragmented.

By completely fragmented I mean as if each write ends up in its own separate 
place on disk and NTFS does not even check whether there is free space after 
the last written block. Honestly, FAT was more efficient - at least when 
written anew there was no fragmentation.

best

Vladimir Dergachev

>
> Christian



--
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: NTFS fragmentation

[Dave Korn]

On 03 August 2006 18:50, Vladimir Dergachev wrote:

> On Thursday 03 August 2006 5:18 am, Dave Korn wrote:
>> On 03 August 2006 00:46, Vladimir Dergachev wrote:
>> 
>> 
>> Hi Vladimir,
>> 
> Please CC me - I am not on the list.
>> 
>>   Done :)
>> 
> 
>>   Actually, maybe the most informative thing would be to look at the device
>> IO controls sent by both testcases, using filemon or similar.
> 
> Thank you for the suggestion !
> 
> I used filemon and discovered that all three programs (ntfs_test.tcl,
> Firefox and IE) use sequential access, but IE writes the file first to
> Temporary Internet Files folder and then copies it.
> 
> If one runs analyze from defragmenter while IE is still downloading the file
> the file in the Temporary Internet Files folder is just as fragmented as
> other files.
> 
> I guess this means that sequential writes are officially broken on NTFS.
> 
> Anyone has any idea for a workaround ? It would be nice if a simple
> tar zcvf a.tgz * does not result in a completely fragmented file.


  I can only think of one thing worth trying off the top of my head: what
happens if you open a file (in non-sparse mode) and immediately seek to the
file size, then seek back to the start and actually write the contents?  Or
perhaps after seeking to the end you'd need to write (at least) a single byte,
then seek back to the beginning?



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: Make command error in Cygwin

[Dave Korn]

On 03 August 2006 18:32, [EMAIL PROTECTED] wrote:

> Hi all,
> I am trying to run Httperf tool in Cygwin. The Cygwin and httperf
> are both installed on saperate drives on my syteam running win2000 the
> steps involved in running httperf in cygwin are
> 
> making a build directory and the navigatinig to the build directory and
> configuring the tool from the build directory and finally issuing a
> make command from the build directory. However I am stuck in the final
> step whenever I issue a make command I get the following error:
> 
> /cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:83: warning: no
> semicolon at end of struct or union
> /cygdrive/d/Abhi/http/test/httperf-0.8/stat/basic.c:84: warning: type
> defaults to `int' in declaration of `reply_bytes_received'

  And it's beyond you to think of actually taking a *look* at line 83 of
basic.c?


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/

line endings, file path names (was: Updated: sed-4.1.5-2)

[Joachim Achtzehnter]

Corinna Vinschen wrote:

[JA wrote:]

Thank you very much for this fix. It will make life easier for all of
us who struggle with a mix of native and Cygwin tools. It is very much
appreciated that as far as line endings are concerned the attitude
taken by Cygwin developers is not "use POSIX line endings".


Sorry, but that's not why I did it.  My personal opinion is still 
strongly on the "use POSIX line endings" side.


Too bad.


I made the fix only so that other mailing lists don't suffer


This is a strange reason for changing sed's functional behaviour, but since
I like the outcome I won't complain. :-)


CRLF lineendings are in the top 10 of the worst ideas in the OS
business.


I agree 100%, and I also agree that DOS path names were a horrendous idea 
too, but neither of these questions are at issue here.



and I'm seriously contemplating (for years) to just remove textmode
from Cygwin.


This is where I disagree completely. From "CRLF was a bad idea" does not 
follow "hence we should not support it". This would just be sticking your 
head in the sand. Bad idea or not, you, or rather a text processing tool 
like sed, cannot avoid being faced by millions of documents that use CRLF 
and a few with Mac line endings too. The realization that it was a bad idea 
does not make these go away.


The only realistic approach here, and more so with line endings than with 
the path name issue, is that taken by XML (about which I usually have no 
good word to say):


 2.11 End-of-Line Handling

 XML parsed entities are often stored in computer files which, for editing
 convenience, are organized into lines. These lines are typically separated
 by some combination of the characters carriage-return (#xD) and line-feed
 (#xA).

 To simplify the tasks of applications, the characters passed to an
 application by the XML processor must be as if the XML processor
 normalized all line breaks in external parsed entities (including the
 document entity) on input, before parsing, by translating both the
 two-character sequence #xD #xA and any #xD that is not followed by #xA
 to a single #xA character.

With respect to "text mode" don't forget that this is also part of the ISO 
standard for C and C++, although those standards don't go as far as XML does.


Another way to look at the issue: You can definitely always blame the whole 
mess on those who started the whole CRLF thing and I'm all on your side, 
but users of your tools will have to muddle through this mess one way or 
another. You can make it easier for your users by making the tools tolerate 
 inputs that are affected by the mess that exists in real life, or you can 
make it difficult. If you take the latter route people will gravitate 
toward other tools in the long run. Cygwin has become as popular as it is 
because it helped get the job done, where the job is dealing with a mixed 
environment (POSIX-like behaviour in a non-POSIX environment).


Joachim

--
work: [EMAIL PROTECTED]   (http://www.netacquire.com)
private:  [EMAIL PROTECTED]  (http://www.kraut.ca)

--
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: NTFS fragmentation

[Vladimir Dergachev]

On Thursday 03 August 2006 2:37 pm, Dave Korn wrote:
> On 03 August 2006 18:50, Vladimir Dergachev wrote:
> > On Thursday 03 August 2006 5:18 am, Dave Korn wrote:
> >> On 03 August 2006 00:46, Vladimir Dergachev wrote:
> >>
> >>
> >> Hi Vladimir,
> >>
> > Please CC me - I am not on the list.
> >>
> >>   Done :)
> >>
> >
> > I guess this means that sequential writes are officially broken on NTFS.
> >
> > Anyone has any idea for a workaround ? It would be nice if a simple
> > tar zcvf a.tgz * does not result in a completely fragmented file.
>
>   I can only think of one thing worth trying off the top of my head: what
> happens if you open a file (in non-sparse mode) and immediately seek to the
> file size, then seek back to the start and actually write the contents?  Or
> perhaps after seeking to the end you'd need to write (at least) a single
> byte, then seek back to the beginning?
>

I am not sure that I understand, if one creates the file and then seeks to 
+1G, wouldn't the file pointer be still at 0 as the filesize is 0 ?

What I am thinking about is modifying cygwin's open and write calls so that 
they preallocate files in chunks of 10MB (configurable by an environment 
variable). 

This way we still get some fragmentation, but it would not be so bad - 
assuming 50MB/sec disk read speed reading 10MB will take 200ms, while a seek 
is at worst 20ms (usually around 10-15ms).

 best

Vladimir Dergachev


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

Re: cygwin copy problems usb 2.0

[Corinna Vinschen]

On Aug  3 13:22, Igor Peshansky wrote:
> On Thu, 3 Aug 2006, Corinna Vinschen wrote:
> > On Aug  3 01:54, Eric Blake wrote:
> > > it would be accepted upstream.  Now if there were something more
> > > POSIX-y that we could do to speed things up, such as posix_fadvise,
> >
> > posix_fadvise can't be implemented nicely, AFAICS.  The POSIX semantics
> > require an already opened file and the advice is given for an offset and
> > a length.  The Windows semantics only allow to give the advice for the
> > whole file, and only switching between FILE_SEQUENTIAL_ONLY or "normal",
> > using ZwSetInformationFile.  By re-opening the file using ZwOpenFile it
> > would also be possible to toggle the FILE_RANDOM_ACCESS flag.  Still,
> > it's always for the whole file, not for an area giving offset and length.
> 
> Theoretically, it's possible to implement posix_fadvise only for offset=0
> and length=, and have it fail with EINVAL otherwise...
> While technically not POSIX-compliant, it would still allow for better
> implementation of things like copy...

Right.  Now for the next problem.  Could anybody be bothered to actually
test the performance effect of setting FILE_SEQUENTIAL_ONLY when reading
and writing files sequentially as cp does?  It would be quite interesting
to get some real numbers on FAT and NTFS, before implementing posix_fadvice
just to find out that it has no practical effect.  If it's less than 10%
it's not worth the effort, imo.


Corinna

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

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

Re: line endings, file path names (was: Updated: sed-4.1.5-2)

[Corinna Vinschen]

On Aug  3 11:43, Joachim Achtzehnter wrote:
> Corinna Vinschen wrote:
> >and I'm seriously contemplating (for years) to just remove textmode
> >from Cygwin.
> 
> This is where I disagree completely. From "CRLF was a bad idea" does not 
> follow "hence we should not support it". This would just be sticking your 
> head in the sand. Bad idea or not, you, or rather a text processing tool 
> like sed, cannot avoid being faced by millions of documents that use CRLF 
> and a few with Mac line endings too. The realization that it was a bad idea 
> does not make these go away.

So, since millions of users have DOS and Mac lineending files, every
system in the world has to support them?  You're out of luck.  Sed does
not support CRLF and CR line endings on POSIX systems.  It just has a
bad hack for Windows systems which is also enabled for Cygwin.  On other
systems you have to take the official route over dos2unix or recode or
whatever.  Oh well, the longer this discussion takes, the more I regret
my decision to revert sed to textmode.


Corinna

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

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

Re: NTFS fragmentation

[Corinna Vinschen]

On Aug  3 14:54, Vladimir Dergachev wrote:
> On Thursday 03 August 2006 2:37 pm, Dave Korn wrote:
> What I am thinking about is modifying cygwin's open and write calls so that 
> they preallocate files in chunks of 10MB (configurable by an environment 
> variable). 

No.


Corinna

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

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

Re: cygwin copy problems usb 2.0

[Eric Blake]

> 
> Theoretically, it's possible to implement posix_fadvise only for offset=0
> and length=, and have it fail with EINVAL otherwise...
> While technically not POSIX-compliant, it would still allow for better
> implementation of things like copy...

Even better, have it return 0 for success but do nothing when offset!=0
or len!= 0.  It's called posix_fadvise for a reason - the implementation is
free to ignore the advice when it can't reasonably use it.  EINVAL should
only be used when passing a bad argument (ie. outside the range of
defined POSIX_FADV_* constants).

There is also posix_fallocate, which may help the case of cp.

-- 
Eric Blake

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

Re: cygwin copy problems usb 2.0

[Corinna Vinschen]

On Aug  3 19:08, Eric Blake wrote:
> > 
> > Theoretically, it's possible to implement posix_fadvise only for offset=0
> > and length=, and have it fail with EINVAL otherwise...
> > While technically not POSIX-compliant, it would still allow for better
> > implementation of things like copy...
> 
> Even better, have it return 0 for success but do nothing when offset!=0
> or len!= 0.  It's called posix_fadvise for a reason - the implementation is
> free to ignore the advice when it can't reasonably use it.  EINVAL should
> only be used when passing a bad argument (ie. outside the range of
> defined POSIX_FADV_* constants).
> 
> There is also posix_fallocate, which may help the case of cp.

Does cp already use ftruncate?


Corinna

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

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

Re: cygwin copy problems usb 2.0

[Eric Blake]

Corinna Vinschen  cygwin.com> writes:

> 
> Does cp already use ftruncate?

Yes, when copying from one regular file to another, cp (and mv and install, 
which share the same code for file copies) uses ftruncate.  But it currently 
only uses it for creating holes at the tail end of sparse files, relying on 
lseek for holes in the middle.  It currently does not use posix_f
{allocate/advise), although I think such a patch would be useful independently 
of cygwin.

-- 
Eric Blake





--
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: Windows popup/message box?

[Reini Urban]

2006/8/3, Igor Peshansky <[EMAIL PROTECTED]>:

On Wed, 2 Aug 2006, Igor Peshansky wrote:

> $ perl -e 'use Win32::GUI qw(MessageBox); MessageBox(0, "message", "title", 
64);'
> Can't load '/usr/lib/perl5/site_perl/5.8/cygwin/auto/Win32/GUI/GUI.dll' for 
module Win32::GUI: No such file or directory at 
/usr/lib/perl5/5.8/cygwin/DynaLoader.pm line 230.
>  at -e line 1
> Compilation failed in require at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
>
> At this point the perl.exe process started consuming 100% of the CPU and
> allocating memory like crazy.  I let it get to 1.2G before killing it
> (took about 35 minutes).  It did react to a Ctrl-C in the parent bash
> window.
>
> I wasn't able to open another Cygwin window and attach to the hanging
> process with strace, because my system slowed down to a crawl and stopped
> responding to most window messages.  Perhaps I'll repeat the experiment
> someday.

Actually, in a typical "D'oh!" moment I realized that I can simply start
the perl process under strace -- if I kill it early enough, it doesn't
affect my system too much.  The strace wasn't very illuminating as to the
cause of not finding the DLL (Windows error 126), but it did have a weird
sequence of mmap()/munmap() that seems to be the cause of 100% CPU and the
virtual memory allocation.


Interesting. Does it go away a rebaseall?


If you're interested in tracking this down further, I can send you the
strace off-list.


If it doesn't go away, yes please.  Something for p5p maybe
--
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

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

Re: Windows popup/message box?

[Reini Urban]

Interesting. Does it go away a rebaseall?


I meant: Interesting. Does it go away after a rebaseall?

--
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: memory problems with cvs gnu emacs on latest cygwin

[Reini Urban]

emacs user schrieb:
I have reported this problem to the gnu emacs developers a few times, 
but it seems that emacs is not actively maintained for cygwin right 
now.  perhaps someone here can help?  I am happy to provide more details 
if needed.   thanks...


A brief problem description:

memory usage of emacs does not decrease after killing buffers with images.


This is lisp (emacs lisp), so it's a feature not a bug.


emacs.exe -q --no-site-file&
the memory usage right after startup is 14912;
after editing a small image: 16452;
after killing the buffer with the image and using M-:(clear-image-cache 
t)RET: 16476;

after editing a large image: 39164;
again quit+clear cache: 34484;
edit small+medium+large images: 58936;
quit+clear: 87636...  (increased!)


overall memory usage in most lisp's doesn't decrease on released 
objects. memory usage is reclaimed when the garbage collector starts its 
walk, which happens when there's not enough memory.


--
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: line endings, file path names

[Joachim Achtzehnter]

Hi Corinna,

You wrote:

So, since millions of users have DOS and Mac lineending files, every 
system in the world has to support them?


I'm not suggesting that any system "has to" do anything, as the author or
funder of a system you can decide what you want it to do. I'm trying to
persuade you that it would be better for its users, and indirectly even for
you because these kind of discussions would go away, if it did.


Sed does not support CRLF and CR line endings on POSIX systems.


And it can to some extent get away with this because communication programs
like ftp and http clients are supposed to translate line endings to the
native convention when downloading text files from other systems. This
doesn't always work because of user errors and incorrect file types, but on
a native POSIX system one can at least legitimately assume that most files
will have native line endings. In the case of Cygwin such an assumption is
simply not warranted because Cygwin always runs on systems where CRLF is
the native convention.


It just has a bad hack for Windows systems which is also enabled for
Cygwin.


It is "bad" only when compared to a possible world without CRLF, but we, at
least most of us, don't have the luxury of living in such a world.

Software developers are often faced with requirements that seem less than
desirable from an aesthetic point of view and we have to get things working
in spite of it. This is one of those cases.


On other systems you have to take the official route over dos2unix or
recode or whatever.


As I tried to explain above, at least on those other systems the need for
dos2unix might be the exception instead of the rule. In spite of this,
given that CRLF platforms are now so wide-spread and given how systems are
now so inter-connected, even UNIX users are likely to benefit from text
processing tools that tolerate both conventions, c.f. the pragmatic
approach taken by XML.


Oh well, the longer this discussion takes, the more I regret my decision
to revert sed to textmode.


This means my argumentation has been counter-productive. :(

Note, I realize how entrenched the opposite point of view seems to be in
this community and I don't have any illusions of quickly converting
everybody. By sticking to arguments instead of emotions I was trying to
avoid this very reaction of yours. My goal is to plant a thought in the
back of people's minds so that perhaps gradually they might begin to
appreciate my point of view and take it into account a little bit when 
similar calls need to be made again about one detail or another.


Thanks for reading,

Joachim

--
work: [EMAIL PROTECTED]   (http://www.netacquire.com)
private:  [EMAIL PROTECTED]  (http://www.kraut.ca)

--
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, Coda and symbolic links

[Adam Wolbach]

Hello cygwin mailing list,

I'm a new subscriber looking to get some information relevant to the 
Coda File System development at Carnegie Mellon University, which uses 
cygwin as a platform to run on Windows 2000/WinXP. We rely heavily on 
symbolic links for a number of different features, most significantly 
representing conflicts within the file system. Conflicts are 
inconsistent file system objects which are represented as "dangling" or 
"broken" symlinks pointing to the file identifier of the inconsistent 
object, e.g., if "foo" fell into conflict:


[host]# ls -l foo
lr--r--r-- 1 root nfsnobody [date/time] foo -> 
@[EMAIL PROTECTED]


Coda's current symlink support in cygwin is nonexistent, but we are 
looking to support symlinks in the same manner cygwin appears to -- as 
special Windows shortcuts that cygwin can interpret as symlinks. 
Allowing cygwin to see our conflicts as broken symlinks would be a big 
win for our repair mechanisms. We looked at the internals of a Windows 
.lnk shortcut file and (of course) part appears binary; we assume 
somewhere along the line that the cygwin developers reverse-engineered 
the contents of these files to hijack them for their own purposes.


First question, I've hunted for this information around the website, in 
the past mailing-list archives and the web, and it doesn't appear 
readily available. Is there anyone on the list who knows more about the 
internals of Windows shortcuts and could clue the Coda developers in? 
Also, how these shortcuts should be crafted to appear as symlinks to 
cygwin? We already know that they must be read-only files from Windows' 
perspective, and cygwin appears to use the "comment" field under 
Properties for its own addressing.


Secondly, is there a more appropriate mailing list for this question? 
(maybe the developers' list?)


Any information is appreciated, as well as a reply-all on any replies. 
Thanks!



Adam Wolbach

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

Re: cygwin, Coda and symbolic links

[mwoehlke]

Adam Wolbach wrote:
I'm a new subscriber looking to get some information relevant to the 
Coda File System development at Carnegie Mellon University, which uses 
cygwin as a platform to run on Windows 2000/WinXP. We rely heavily on 
symbolic links for a number of different features, most significantly 
representing conflicts within the file system. Conflicts are 
inconsistent file system objects which are represented as "dangling" or 
"broken" symlinks pointing to the file identifier of the inconsistent 
object, e.g., if "foo" fell into conflict:


[host]# ls -l foo
lr--r--r-- 1 root nfsnobody [date/time] foo -> 
@[EMAIL PROTECTED]


Coda's current symlink support in cygwin is nonexistent, but we are 
looking to support symlinks in the same manner cygwin appears to -- as 
special Windows shortcuts that cygwin can interpret as symlinks. 
Allowing cygwin to see our conflicts as broken symlinks would be a big 
win for our repair mechanisms. We looked at the internals of a Windows 
.lnk shortcut file and (of course) part appears binary; we assume 
somewhere along the line that the cygwin developers reverse-engineered 
the contents of these files to hijack them for their own purposes.


First question, I've hunted for this information around the website, in 
the past mailing-list archives and the web, and it doesn't appear 
readily available. Is there anyone on the list who knows more about the 
internals of Windows shortcuts and could clue the Coda developers in? 
Also, how these shortcuts should be crafted to appear as symlinks to 
cygwin?


Maybe you could look at Cygwin's source code where it writes .lnk files? 
Or don't bother, link against Cygwin, and use "symlink()".


--
Matthew
And now back to your regularly scheduled e-mail.


--
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: GnuPG bug: --refresh-keys

[Max Bowsher]

Max Bowsher wrote:
> When running 'gpg --refresh-keys', the second updated key results in:
> 
> gpg: renaming `/home/max/.gnupg/pubring.gpg' to
> `/home/max/.gnupg/pubring.gpg~' failed: Permission denied
> gpg: error writing keyring `/home/max/.gnupg/pubring.gpg': file rename error
> gpg: key : "" 28 new signatures
> gpg: error reading `[stream]': file rename error
> 
> 
> Given that:
>  * this happens for the *second* updated key
> 
>  * having another process running at the same time, rapidly moving away
> any new pubring.gpg~ files avoids the error
> 
>  * it is presumably Cygwin-specific
> 
> it seems extremely likely that gnupg has a file descriptor leak, such
> that when the second key is processed, gnupg still has an open file
> descriptor on the file pubring.gpg~ when it attempts to overwrite it by
> renaming another file onto that name. Windows then objects.


Replying to my own mail...

GPG for some reason tries to cache opened fds for re-use. I suggest
disabling this caching for Cygwin. The appropriate code to tweak is in
util/iobuf.c:fd_cache_close(). I changed the condition of the first if
statement there to always be true, and the problem I reported goes away.

Please integrate this into the Cygwin packages.

Thanks,
Max.



signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] clisp-2.39-1 released

[Reini Urban]

I've taken over clisp maintainance from Sam Steingold, who lost access 
to his windows box and to this list. Thanks Sam for a wonderful job anyway!
clisp-2.39-1 is now built with cygport, but you can still compile it 
with ./configure; make; make install also.


./configure --fsstnd=redhat --with-dynamic-ffi  \
--with-module=rawsock --with-module=dirkey  \
--with-module=bindings/win32 --with-module=berkeley-db \
--with-module=pcre --with-module=postgresql \
--with-module=fastcgi --prefix=/usr --build build

Notes:
Built against the new libsigsegv-2.4.
There's the new module fastcgi, which is recommended for lighttpd.
--with-dynamic-modules doesn't build yet, but it is in the works. This 
would allow to support more modules, like matlab, oracle, pari and netica.
I thought --without-unicode would be a good idea, so you can omit the 
sometimes necessary and disturbing -E arg, but this will lead to a lot 
of problems with some asdf packages. So it's UNICODE and ENCODING enabled.
It is now possible to create standalone exe files. Well at least the 
cygwin1.dll is required, so you might prefer the mingw build for this 
feature.


ANSI Common Lisp is a high-level, general-purpose programming language.
It mostly supports the Lisp described in the ANSI Common Lisp standard.
It is Free Software and may be distributed under the terms of GNU GPL,
while it is possible to distribute commercial proprietary applications
compiled with GNU CLISP.
GNU CLISP includes an interpreter, a compiler, a debugger, CLOS, MOP,
a foreign language interface, sockets, i18n, fast bignums, fast IO and more.
GNU CLISP runs Maxima, ACL2 and many other Common Lisp packages.

http://clisp.cons.org/

What's New:
http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/NEWS

User visible changes


* SAVEINITMEM now accepts :SCRIPT argument that disables interpreting
  the first positional argument as the script name; and :DOCUMENTATION
  argument that is printed by the new -help-image command line option.
  See  and
   for
  details.

* FFI:UINT64 and FFI:SINT64 are now compatible with C's long long type.

* Stack overflow detection and recovery finally work fine on Unix.
  Libsigsegv is required for this, on all platforms (including
  MS-Windows).
  CLISP should neither exit nor crash under infinite recursion.
  If your distribution has CLISP compiled without libsigsegv, report
  the missing feature to its maintainer.
  Note that libsigsegv 2.4 is required, there are bugs in libsigsegv
  2.3!

* It is now possible to specify the default method-combination of a
  generic function, to be used when the DEFGENERIC form does not specify
  the :METHOD-COMBINATION explicitly, through a default initarg
  specification for the :METHOD-COMBINATION keyword on the generic
  function class.

* Readline completion works with non 1:1 terminal encodings, e.g. UTF-8.

* WITH-KEYBOARD works with a Unix tty even when SLIME hijacks
 *TERMINAL-IO*.

* I/O operations on Win32 are now much faster.

* New functions: POSIX:FFS, POSIX:PATHCONF.

* Infrastructure:
  + Top-level configure now accepts a new option --with-gmalloc to use
the GNU malloc implementation instead of the one supplied by libc.
You may need it on older HP-UX and newer OpenBSD systems.
See file unix/PLATFORMS for more information.
  + The value of the environment variable CFLAGS is respected by
configure.

* Bug fixes:
  + SOCKET:SOCKET-SERVER :INTERFACE now behaves as documented.
  + EXT:READ-BYTE-NO-HANG and SOCKET:SOCKET-STATUS used to hang on
buffered binary sockets.
  + Allow DESTRUCTURING-BIND (a . b) with circular and dotted lists.
  + ADJUST-ARRAY of zero length adjustable string now works.
  + TIME now reports correct results when the heap grows over 4GB.
  + RAWSOCK functions now handle :START/:END arguments correctly.
  + BDB:DBC-GET now accepts :READ-COMMITTED and :READ-UNCOMMITTED.
  + POSIX:GROUP-INFO and POSIX:USER-INFO now handle errors correctly.

* Portability:
  + Support DragonFly BSD



To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Reini Urban

--
Unsubscribe info:  http://cygwin.com/ml

RE: [ANNOUNCEMENT] clisp-2.39-1 released

[Billinghurst, David \(CALCRTS\)]

> From: Reini Urban
> 
> I've taken over clisp maintainance from Sam Steingold, who 
> lost access to his windows box and to this list.

Thanks.   It successfully builds the maxima-5.10 release candidate 1.

David


NOTICE
This e-mail and any attachments are private and confidential and may contain 
privileged information. If you are not an authorised recipient, the copying or 
distribution of this e-mail and any attachments is prohibited and you must not 
read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.

--
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: memory problems with cvs gnu emacs on latest cygwin

[emacs user]

From: Reini Urban
emacs user schrieb:

I have reported this problem to the gnu emacs developers a few
times, but it seems that emacs is not actively maintained for cygwin
right now. perhaps someone here can help? I am happy to provide more
details if needed. thanks...

A brief problem description:

memory usage of emacs does not decrease after killing buffers
with images.


This is lisp (emacs lisp), so it's a feature not a bug.


thanks for responding, although this is incorrect, please see below.



emacs.exe -q --no-site-file&
the memory usage right after startup is 14912;
after editing a small image: 16452;
after killing the buffer with the image and using
M-:(clear-image-cache t)RET: 16476; after editing a large image: 
39164;

again quit+clear cache: 34484;
edit small+medium+large images: 58936;
quit+clear: 87636... (increased!)


overall memory usage in most lisp's doesn't decrease on released
objects. memory usage is reclaimed when the garbage collector
starts its walk, which happens when there's not enough memory.



that's actually not true.  the simple observation is that the bug I
describe does not occur on other platforms such as gnu/Linux.  memory
is returned to the operating system after the buffer is killed.

best, EU

_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



--
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: GnuPG bug: --refresh-keys

[Volker Quetschke]

Max Bowsher wrote:
> Max Bowsher wrote:
>> When running 'gpg --refresh-keys', the second updated key results in:
>>
>> gpg: renaming `/home/max/.gnupg/pubring.gpg' to
>> `/home/max/.gnupg/pubring.gpg~' failed: Permission denied
>> gpg: error writing keyring `/home/max/.gnupg/pubring.gpg': file rename error
>> gpg: key : "" 28 new signatures
>> gpg: error reading `[stream]': file rename error
>>
>>
>> Given that:
>>  * this happens for the *second* updated key
>>
>>  * having another process running at the same time, rapidly moving away
>> any new pubring.gpg~ files avoids the error
>>
>>  * it is presumably Cygwin-specific
>>
>> it seems extremely likely that gnupg has a file descriptor leak, such
>> that when the second key is processed, gnupg still has an open file
>> descriptor on the file pubring.gpg~ when it attempts to overwrite it by
>> renaming another file onto that name. Windows then objects.
> 
> Replying to my own mail...
> 
> GPG for some reason tries to cache opened fds for re-use. I suggest
> disabling this caching for Cygwin. The appropriate code to tweak is in
> util/iobuf.c:fd_cache_close(). I changed the condition of the first if
> statement there to always be true, and the problem I reported goes away.
> 
> Please integrate this into the Cygwin packages.

Thanks for tracking this down Max. It's also time for a new package
with the newer upstream version.

   Volker

-- 
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D



signature.asc
Description: OpenPGP digital signature

Re: cygwin and db2

[prz]

Just to inform others that the problem has been corrected by db2 team.
export DB2CLP=**$$**   corrected the problem...
Best Regards, Guy Przytula
-- 
View this message in context: 
http://www.nabble.com/cygwin-and-db2-tf2008740.html#a5645136
Sent from the Cygwin Users forum at Nabble.com.


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

1.5.21-2: missing announcement?

[Danilo Turina]

Yesterday Setup.exe showed to me a new versione of the cygwin dll 
(1.5.21-2) but I didn't notice any announcement about it.


Is the announcement missing or the mirror wrong (mirrors.kernel.org)?

Ciao,

Danilo


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

Problem using shorcut keys

[Shivakumar T.]

Hi,

I am using Cygwin 5.1 from my Win XP box to connect to Solaris machine.

When i run any graphical text editor like nedit, with the numlock turned on I 
am not able to use the shortcut keys like Ctrl+S.

When i do so  gets typed. When i do the same after turning Numlock off it 
works fine.

This is not the problem with all the shortcut keys only a few shortcuts give me 
this problem.

Please help me.

Thanks and regards,

Shiva Kumar T

Mobile: +91 9880593278

Extn: 54918


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

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