message for the EIO error

Hello, In the winsup directory (winsup/cygwin/errno.c), i can observe that the error EIO is attributed the message Input/Output error. In the newlib directory (newlib/libc/sys/linux/dl/dl-minimal.c) the same EIO is attributed the message Input/output error. This the same message, but not

cygcheck's understanding of TZ

Hello, It seems that /usr/bin/cygcheck does not interpret TZ the same way as /usr/bin/date does, in the case TZ is set to a file name, like in the following example: (under tcsh) jupiter% alias cygdate 'cygcheck -s | head -3' jupiter% (setenv TZ /usr/share/zoneinfo/Europe/Monaco; date;

snapshot 20110528 works, 20110530 not

Hello, The following script: - #!/bin/csh -f /bin/ls /cygdrive | /bin/grep . set x = `/bin/ls /cygdrive | /bin/grep .` echo zz $x zz - produces c e g h o p s zz c e g h o p s Broken pipe zz

Re: CMD.EXE able to create files in directories on a shared drive, but bash in cygwin is unable to

Hello, This one is a follow-up for http://cygwin.com/ml/cygwin/2011-05/msg00183.html On 2011-05-12 09:47:15 -0600 Keith Christian wrote: This permissions problem has existed for awhile, and I'd like to find a solution. Same for me. CMD.EXE is able to create files inside directories on a

Re: difficulties with snapshots

Hello, This one is a follow-up of http://cygwin.com/ml/cygwin/2011-05/msg00042.html On 2011-05-05 11:19:56 -0400, Christopher Faylor wrote: On Thu, May 05, 2011 at 10:47:39AM +0200, EXCOFFIER Denis wrote: 2) More importantly, i was not able to compile snapshots since about beginning of May

difficulties with snapshots

Hi, 1) It seems that we have management problems with the snapshots. The last one (indicated 2011-05-04 01:02:18 UTC) belongs in fact to 2011-05-05, and it is more recent than the preceding snapshot (indicated yesterday 2011-05-04 06:xx:xx UTC), which has now disappeared (diffs are shown against

Re: [ANNOUNCEMENT] Updated: cygutils-1.4.6-1

Hi, This message is a follow-up for http://cygwin.com/ml/cygwin/2011-04/msg00411.html A suggestion for an improvement of readshortcut.exe can be found at http://cygwin.com/ml/cygwin/2010-05/msg00075.html Please use the idea. Regards, Denis Excoffier.

last snapshot (2011-03-13)

Hello, Please consider http://cygwin.com/ml/cygwin/2011-03/msg00436.html In fhandler.h i changed DEFAULT_PIPEBUFSIZE back to contain PREFERRED_IO_BLKSIZE (instead of 31*1024*1024), installed the new cygwin1.dll and of course, no more problem. I also performed extended tests on another Windows

last snapshot (2011-03-13)

This message follows http://cygwin.com/ml/cygwin/2011-03/msg00539.html Both system are Microsoft Windows XP Professional Version 2002 Service Pack 3. The system that produces the File too large error is: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz 3.00 GHz, 3.48 GB of RAM The system where i'm

last snapshot (2011-03-18)

This follows http://cygwin.com/ml/cygwin/2011-03/msg00549.html You say change it back as if that was the only change. It wasn't. The meaning changed in recent snapshots. In fact, i created a snapshot 20110313++, where the only change wrt 20110313 was to replace 31*1024*1024 with

last snapshot (2011-03-13)

This follows http://cygwin.com/ml/cygwin/2011-03/msg00563.html Maybe it has something to do with the nonpaged pool size? MSDN states: Every time a named pipe is created, the system creates the inbound and/or outbound buffers using nonpaged pool, which is the physical memory used by the

cat: write error: File too large

Hello! I'm currently testing the last snapshot 20110313. I've found something curious. % uname -a CYGWIN_NT-5.1 JUPITER043890 1.7.9s(0.236/5/3) 20110313 16:22:37 i686 Cygwin % bzip2 -cd gcc-4.5.2.tar.bz2 /tmp/1 % wc /tmp/1 11426953 43063570 448358400 /tmp/1 % rm /tmp/1 % cat

snapshots revisited

Hello, I'm now happy with the snapshots as they are, and i'm ready to use them more in the future, thank you for them. I'm especially glad that it has no interaction with the regular setup.exe mechanism: if at some point a snapshot is not satisfactory, you just have to Reinstall the regular

tar --atime-preserve with an empty file triggers a warning

Hello, I've the experienced the following (100% reproducible under 1.7.7-1 or 1.7.8-1): % cp /dev/null empty % tar cf empty.tar --atime-preserve empty /usr/bin/tar: empty: Cannot utime: Invalid argument /usr/bin/tar: Exiting with failure status due to previous errors % Of course the empty.tar

winmm.dll error 487 is easily reproducible

Hello, I get the winmm.dll error 487 (under 1.7.8-1, but not under 1.7.7-1) with the following, easily 100% reproducible: echo dummy text /tmp/foo /usr/bin/xz -8 /tmp/foo /usr/bin/xz -d /tmp/foo.xz --- this produces the error rm -f /tmp/foo /tmp/foo.xz xz is the current one in Cygwin

Re: winmm.dll error 487 is easily reproducible

The latest snapshot (20110301) solves the issue. Thank you. Denis Excoffier. P.S.: By the way, what is the normal way to install snapshots? It is easy to replace cygwin1.dll (keeping around the working one), but in order to test the cygwin1 package in full (eg to check within stdio.h whether