Package: cygwin
Version: 1.7.34-6
Cygwin often hangs up if several keys are input during a lot of text outputs.
To reproduce this problem:
1) Start a new cygwin session on mintty.
2) Execute
yes
or
od /dev/urandom
3) Hit 'a
Package: inetutils-server
Version: 1.9.1-2 or older
Telnetd in inetutils-server package lacks handling of some of
TIOCPKT control bytes. The most influential thing is a lack of
handling of TIOCPKT_DATA. TIOCPKT_DATAs i.e. '\0's frequently
appear in the stream of network side.
In most cases, '\0'
On 2/27/2015 5:49 PM, Bengt Larsson wrote:
Below are two benchmarks that explore maximum floating point
performance. loopm6 is double precision floating point and loopm6fp is
parallell single-precision. They are manually unrolled multiply-add
loops.
I used to reach 2.8 and 11 GFlops on these. No
Hi,
In the last xlaunch package, the etc/postinstall/xlaunch.sh reads:
% cat /etc/postinstall/xlaunch.sh.done
# add a start menu shortcut
case $(uname -s) in *-WOW64) wow64=" (32-bit)" ;; esac
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
/usr/bin/mkshortcut $CYGWINFOR
Hi,
This is a standard makefile, except that hello.c
is taken from a special directory:
% cat Makefile
all : hello
hello : hello.o
gcc -o $@ $+
hello.o : /usr/mydata/hello.c
gcc -o $@ -c $<
clean :
-rm -f hello hello.exe hello.o
%
The file hello.c contains exactly what yo
on the CYGWIN getfacl manpage, it has
-a, --all
display the filename, the owner, the group, and the ACL of the
file
--
But in the linux version it says:
-a, --access
Display the file access control list.
--
The "--all" in the cygwin cygwin version sounds like it
sho
Hi,
Playing with mkgroup and mkpasswd like others, i also
noticed some great improvement in performance:
now less than 5min for 404653 entries (mkpasswd -d)
and less that 1min for 127048 entries (mkgroup -d).
Before it was nearly 1 hour for each.
Playing also with /etc/group, i happened to enter
On 2015-02-27 18:52, Corinna Vinschen wrote:
>
> I released another TEST version of the next upcoming Cygwin release.
>
I have noticed that the behavior of /usr/bin/script is not better than
previously (probably the change resides near
https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
For
The following package has been updated in the Cygwin distribution:
* mscgen-0.20-3
Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.
This release has FreeType font rendering enabled.
Dave
--
Greetings, Habermann, David (D)!
>> Since Cygwin 1.7.34, chmod does not always affect the POSIX permission
>> mask as returned by stat(2) or printed by ls(1), due to the improved
>> POSIX ACL handling. As a temporary workaround, chmod now checks if
> I'm a neophyte regarding this ACL handling
Hi Corinna,
This seems _very_ much improved for the slow start. Thank you!
$ uname -a
CYGWIN_NT-6.1 US00124433 1.7.35(0.286/5/3) 2015-02-27 17:19 x86_64 Cygwin
$ wc /etc/passwd
12608 12617 1472440 /etc/passwd
$ wc /etc/group
12603 12817 939502 /etc/group
Best regards,
Steve
On Fri, Fe
Eric Blake writes:
>> What's really happening is that we need to peek at the first few bytes
>> of f before deciding which program to call in popen. After peeking,
>> there's a call to fseek(f,0,0) before the popen, with the intention that
>> the child receives a file pointer set to the beginning
> Thanks (and thanks to Corinna and Eric) for correcting my misconceptions.
You're welcome. I only wanted to follow up that (I don't know what
the heck happened to my head, but) when I was
referring to file descriptors, I was consistently and mistakenly using
"1" where "0" should have been used:
Hi Corinna,
Ref: https://cygwin.com/ml/cygwin/2015-02/msg00856.html
- Too Many Permissions Stripped In 1.7.35?
Is it true? Is Cygwin a system to manage Windows? I NEVER got that impression.
I have always been content that I was able to use Cygwin in a directory tree,
that had been
especially p
On 2/27/2015 11:20 AM, A L wrote:
I think that would create an unacceptable performance penalty for the child
process.
The child process would not be affected at all! FILE* will be
unbuffered only in your
application, yet "cat" will read from a file descriptor "1" (and may
or may not apply an
> Since Cygwin 1.7.34, chmod does not always affect the POSIX permission
> mask as returned by stat(2) or printed by ls(1), due to the improved
> POSIX ACL handling. As a temporary workaround, chmod now checks if
I'm a neophyte regarding this ACL handling stuff. Here is my usage model,
which
Hi Cygwin friends and users,
I released another TEST version of the next upcoming Cygwin release.
If all is well, I hope this is the final test version before going
full ninja.
Apart from a few bug fixes, this release introduces the following
changes in terms of chmod and ACL handling.
- Change
Below are two benchmarks that explore maximum floating point
performance. loopm6 is double precision floating point and loopm6fp is
parallell single-precision. They are manually unrolled multiply-add
loops.
I used to reach 2.8 and 11 GFlops on these. Now I only get
2 and 6.
If you explore the inn
> I think that would create an unacceptable performance penalty for the child
> process.
The child process would not be affected at all! FILE* will be
unbuffered only in your
application, yet "cat" will read from a file descriptor "1" (and may
or may not apply any
buffering on top of it, such as
On 02/27/2015 05:40 AM, Ken Brown wrote:
>> Wrong expectations. Keep in mind that the default read mode using
>> stdio functions is buffered. So your fread fills the buffer in f.
>> The buffer is typically something like 1K or 4K. If the file is
>> shorter than that, the file pointer will be set
> What I think happens is that since you
> specify a full posix path to cmd, you get posix semantics and none of
> the Windows compatibilty crap kicks in.
that may be, if your very own suggestion to split the last arg in two worked
just fine with the full posix path, i.e. while this set of argumen
Greetings, random user!
> (Less sure I think this is really a good idea, but it'd seem consistent
> with treating SYSTEM this way given the standard default ACLs on
> /c/Users/): Should Administrators be treated the same as SYSTEM?
No, totally.
As I wrote in my list reply, which server appears t
On Feb 27 13:19, Corinna Vinschen wrote:
> On Feb 27 09:57, Achim Gratz wrote:
> > Corinna Vinschen cygwin.com> writes:
> > > Good point. Right now the group permissions are == owner permissions in
> > > the case the owner and group are the same. Maybe it would be better to
> > > remove all grou
On Feb 27 07:40, Ken Brown wrote:
> On 2/27/2015 3:43 AM, Corinna Vinschen wrote:
> >On Feb 26 22:05, Ken Brown wrote:
> >>I'm not sure exactly where the bug is, but here's what happens (STC at the
> >>end):
> >>
> >>1. I use freopen to open a file "foo" and associate it with stdin.
> >>
> >>2. I
On 2/27/2015 3:43 AM, Corinna Vinschen wrote:
On Feb 26 22:05, Ken Brown wrote:
I'm not sure exactly where the bug is, but here's what happens (STC at the end):
1. I use freopen to open a file "foo" and associate it with stdin.
2. I use fread to read a byte from foo.
3. I call popen, expectin
On Feb 27 09:57, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > Good point. Right now the group permissions are == owner permissions in
> > the case the owner and group are the same. Maybe it would be better to
> > remove all group permission bits if owner SID == group SID instead
Corinna Vinschen cygwin.com> writes:
> Good point. Right now the group permissions are == owner permissions in
> the case the owner and group are the same. Maybe it would be better to
> remove all group permission bits if owner SID == group SID instead.
I think that would be defendable since i
On Feb 26 16:18, Eric Blake wrote:
> On 02/26/2015 03:31 PM, Corinna Vinschen wrote:
> > On Feb 26 14:19, Eric Blake wrote:
> >> On 02/26/2015 01:24 PM, Corinna Vinschen wrote:
> > Fixes are in snapshots, as well as test releases (currently 1.7.35-0.4)
> > which can be installed with setup*
On Feb 26 21:27, random user wrote:
> Regarding Corrinne's proposal to treat SYSTEM's ACE distinct from others
> in forming the apparent group permission "mask":
>
> Might it be sensible to do somewhat similar for the case where a file's
> owner is the same as its primary group (i.e., same SID)?
On Feb 27 04:35, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> > given that SYSTEM has permissions to read and write all files
> > anyway.
>
> Not true.
> If SYSTEM don't have access to files, it can't do anything at all.
> This is not Linux, system isn't run from root.
You apparently m
On Feb 27 06:52, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Having discussed this, I can understand that it may be desirable to
> > skip the permissions of the SYSTEM account in these circumstances:
> >
> > - Computing the POSIX ACL mask and default mask value and thus in
> > the permissio
On Feb 26 16:00, Andrew DeFaria wrote:
> On 2/26/2015 2:34 PM, Corinna Vinschen wrote:
> >On Feb 26 14:21, Andrew DeFaria wrote:
> >>On 2/26/2015 12:24 PM, Corinna Vinschen wrote:
> >>>On Feb 26 12:04, Andrew DeFaria wrote:
> On 2/25/2015 4:12 PM, Yaakov Selkowitz wrote:
> >On Wed, 2015-02-
On 2015-02-27 06:03, A L wrote:
> Thank you for your response. It may sound plausible but:
>
>> you tell Cygwin that you want posix semantics
>
> I can't remember seeing that posix semantics require a C library call
> to modify arguments in the way the shell does; since when cygwin a
> shell?
On Thu, 2015-02-26 at 17:31 -0500, David A. Wheeler wrote:
> The Cygwin front web page ( https://www.cygwin.com/ ) says:
> "Install it by running setup-x86.exe (32-bit installation) or
> setup-x86_64.exe (64-bit installation)."
>
> However, both of the links to those .exe executables explicitly
>
On Feb 26 22:05, Ken Brown wrote:
> I'm not sure exactly where the bug is, but here's what happens (STC at the
> end):
>
> 1. I use freopen to open a file "foo" and associate it with stdin.
>
> 2. I use fread to read a byte from foo.
>
> 3. I call popen, expecting the child process to have foo
The following packages have been updated in the Cygwin distribution:
* gcc-core-4.9.2-3
* gcc-ada-4.9.2-3
* gcc-fortran-4.9.2-3
* gcc-g++-4.9.2-3
* gcc-java-4.9.2-3 (i686 only)
* gcc-objc-4.9.2-3
* gcc-objc++-4.9.2-3
* libatomic1-4.9.2-3
* libgcc1-4.9.2-3
* libgcj15-4.9.2-3 (i686 only)
* libgcj-co
36 matches
Mail list logo
