Re: Bug in lrzip 0.631-1 (32 bit version) with -d -o - options

2017-02-04 Thread Marco Atzeri 

On 25/01/2017 23:15, David Balažic wrote:

Hi!

The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
decompressed dat in some circumstances.

I reproduced the problem on 2 PCs (the md5sum of the broken output was
the same on both systems).

I seems to happen when the (de)compressed file size is bigger than the
available RAM (note that the 32 bit version uses max 4GB in any case)
and lrzip resorts to using a temporary file.


[cut]



Simply decompressing the file (lrzip -d -o sda.img sda.img.lrz2) to
filesystem works fine, only when piped to stdout the problem happens.

The 64 bit version does not have this problem.






Regards,
David



can you check if latest cygwin test solves the issue ?
There was a change on pipe handling.

https://cygwin.com/ml/cygwin-announce/2017-02/msg7.html

- Always try to write all incoming bytes to blocking pipes, as required
  by POSIX.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00087.html

Regards
Marco


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

Re: Bug in lrzip 0.631-1 (32 bit version) with -d -o - options

2017-02-04 Thread David Balažic 
Here is a smaller reproducible test case (I did the preparation part
in 64 bit cygwin):

 - download http://releases.ubuntu.com/16.10/ubuntu-16.10-desktop-i386.iso
 - download http://releases.ubuntu.com/16.10/ubuntu-16.10-desktop-amd64.iso

$ md5sum ubuntu-16.10-desktop-i386.iso ubuntu-16.10-desktop-amd64.iso
e9e9a6c6b3c8c265788f4e726af25994 *ubuntu-16.10-desktop-i386.iso
3f50877c05121f7fd8544bef2d722824 *ubuntu-16.10-desktop-amd64.iso

$ cat ubuntu-16.10-desktop-i386.iso ubuntu-16.10-desktop-amd64.iso > test.iso

$ md5sum test.iso
d6e8cb13ce36e2c04961004782eec139 *test.iso

$ lrzip -v test.iso
The following options are in effect for this COMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17160601600 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Temporary Directory set as: /tmp/
Compression mode is: LZMA. LZO Compressibility testing enabled
Heuristically Computed Compression Window: 109 = 10900MB
Output filename is: test.iso.lrz
File size: 3204448256
Will take 1 pass
Beginning rzip pre-processing phase
test.iso - Compression Ratio: 1.352. Average Compression Speed: 15.357MB/s.
Total time: 00:03:18.85

$ lrzip -i test.iso.lrz
test.iso.lrz:
lrzip version: 0.6 file
Compression: rzip + lzma
Decompressed file size: 3204448256
Compressed file size: 2370391407
Compression ratio: 1.352
MD5 used for integrity testing
MD5: d6e8cb13ce36e2c04961004782eec139

in 32 bit cygwin:

$ TMP=/cygdrive/d/tmp/  lrzip -v  -d  -o -
/cygdrive/c/cygwin64/home/stein/test.iso.lrz  | tee >(md5sum --tag)
>(sha1sum --tag) > /dev/null
The following options are in effect for this DECOMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17160601600 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Output Filename Specified: -
Temporary Directory set as: /cygdrive/d/tmp/
Outputting to stdout.
Detected lrzip version 0.6 file.
MD5 being used for integrity testing.
Decompressing...
Unable to decompress entirely in ram, will use physical files
Dumping temporary file to control->outFILE.

Average DeCompression Speed: 29.105MB/s
Dumping temporary file to control->outFILE.
[OK] - 3204448256 bytes
Total time: 00:01:45.07
SHA1 (-) = da39a3ee5e6b4b0d3255bfef95601890afd80709
MD5 (-) = d41d8cd98f00b204e9800998ecf8427e

The MD5 sum is wrong. (both md5 and sha1 values are the hashes of an
empty file, so the data is lost somewhere)

I attach the cygcheck -s -v -r output again (with cygwin 2.7.0-0.1 , I
later checked with 2.7.0-0.2 too, got the same results)

Regards,
David


On 1 February 2017 at 22:25, David Balažic  wrote:
> I tried the  2.7.0-0.1  test release and now the behavior changed.
>
> Before I got consistently a wrong MD5 sum of 8bd6ad48f2cea6a710af70b434d57673
> With this release I get c43a02c309fa5e0abe778201e9ceec46.
>
> So something changed.
>
> Either the problem is in cygwin or lrzip, I guess.
>
> Regards,
> David
>
>
> On 30 January 2017 at 16:23, David Balažic  wrote:
>> I tried in Ubuntu 32 bit (both the packaged lrzip  and a self compiled
>> one) and there the problem does not happen, so it looks like either:
>>  - bad lrzip in cygwin
>>  - cygwin pipe issues?
>>
>> Regards,
>> David
>>
>>
>> On 25 January 2017 at 23:15, David Balažic  wrote:
>>> Hi!
>>>
>>> The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
>>> decompressed dat in some circumstances.
>>>
>>> I reproduced the problem on 2 PCs (the md5sum of the broken output was
>>> the same on both systems).
>>>
>>> I seems to happen when the (de)compressed file size is bigger than the
>>> available RAM (note that the 32 bit version uses max 4GB in any case)
>>> and lrzip resorts to using a temporary file.
>>>
>>> See below for reproducing:
>>>
>>> $ lrzip -i sda.img.lrz2
>>> sda.img.lrz2:
>>> lrzip version: 0.6 file
>>> Compression: rzip + lzma
>>> Decompressed file size: 64017212928
>>> Compressed file size: 7210541304
>>> Compression ratio: 8.878
>>> MD5 used for integrity testing
>>> MD5: 6594f5b0d22efd345003260054165842
>>>
>>> $ date; df -h ; TMP=/cygdrive/i/t/tmp/  lrzip -v  -d  -o -
>>> sda.img.lrz2  | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null   ;
>>> date
>>> Tue Jan 24 21:29:01 CET 2017
>>> Filesystem  Size  Used Avail Use% Mounted on
>>> C:/cygwin   114G   94G   21G  83% /
>>> D:  541G  534G  7.1G  99% /cygdrive/d
>>> I:  391G  279G  113G  72% /cygdrive/i
>>> Q:   60G   57G  2.8G  96% /cygdrive/q
>>> The following options are in effect for this DECOMPRESSION.
>>> Threading is ENABLED. Number of CPUs detected: 4
>>> Detected 17160601600 bytes ram
>>> Compression level 7
>>> Nice Value: 19
>>> Show Progress
>>> Verbose
>>> Output Filename Specified: -
>>> Temporary Directory set as: /cygdrive/i/t/tmp/
>>> Outputting to stdout.
>>> Detected lrzip version 0.6 file.
>>> MD5 being used for integrity testing.
>>> Decompressing...
>>> Unable to decompress entirely in ram, will use

Re: Is it OK to mount cygdrive on / ? (usually, but may not be as portable).

2017-02-04 Thread L. A. Walsh 

Andrey Repin wrote:
Accessing drive letters directly from inside Cygwin is often 
considered a grey area.


   How is it grey?


Too much may happen on this border. You have to clearly understand, how Cygwin 
interact with other system, to avoid issues.
  


I.e. if you think you may have programs that also want to use
/bin /usr, /sbin, /lib /etc, there could be conflicts.



If you want to access Windows path, recommended route lies through the use of
cygpath utility to convert native paths to the Cygwin scheme. Et vice versa.
  

I wouldn't recommend that -- it's too hard to type:

/> ls -d $(cygpath S:\Music\Anime)   
ls: cannot access S:MusicAnime: No such file or directory

/> ls -d $(cygpath 'S:\Music\Anime')
/s/Music/Anime/
...(vs.)
/> ls -d /s/Music/Anime
/s/Music/Anime/
-or-
ls -d $(cygpath \\ishtar\Music)
ls: cannot access /ishtarMusic: No such file or directory
/> ls -d $(cygpath '\\ishtar\Music')
//ishtar/Music/
---
Much easier just to type "//hostname/Share".


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

Re: [ANNOUNCEMENT] Updated: octave forge packages

2017-02-04 Thread Achim Gratz 
Marco Atzeri writes:
> I will look again
> http://savannah.gnu.org/bugs/?func=detailitem_id=47761

Ah OK, so I did already report that earlier and was just not finding the
discussion.

> It is a bug from the upstream code.
> http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/index.html

Yeah, I looked at it… still gives me the shivers.

> I tried to patch it last year but I was not successful,
> I will look again.

Just cut down the nx parameter in all the Fortran files by a factor of
10 (from 1e6 to 1e5).  They don't let you do this from configure, so
you'll need a patch script and/or sed apparently.  At least it looks
like they always call that parameter nx.  Probably none of these should
have been static arrays in the first place, but that's a lot harder to
fix.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Houder 
On Sat, 4 Feb 2017 18:16:10, Corinna Vinschen wrote:
[snip]
> Works fine for me in dash as well as in od in a console with cp437:
> 
>   $ od -tx1
>   <^J><^D>
>   =E2=98=BA
>   000 e2 98 ba 0a
>   004
>   $ od -tx1
>   <^J><^D>
>   000 0a
>   001
>   $ od -tx1
>   <^J><^D>
>   =E2=96=A0
>   000 e2 96 a0 0a
>   004
>   $ od -tx1
>   <^J><^D>
>   000 0a
>   001

I could NOT believe your reply ... until I noticed that the NumLock had been
switched ON ... Oh J. ...

Switching NumLock OFF:

Using Windows Console (cp437)

64-@@ od -tx1
<^J><^D>
■
000 e2 96 a0 0a
004
64-@@ dash
# enter alt-254
$ echo ■ | od -tx1
000 e2 96 a0 0a
004
$ exit
64-@@ bash --noediting
=> LANG = en_US.UTF-8
64-@@ od -tx1
<^J><^D>
■
000 e2 96 a0 0a
004
64-@@

Ai, ai, ai, my bad. My apologies!

Signing off from keyboard NOW!

R. Henri

==


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

Re: [ANNOUNCEMENT] Updated: octave forge packages

2017-02-04 Thread Marco Atzeri 

On 04/02/2017 16:54, Achim Gratz wrote:

Marco Atzeri writes:

octave-tisean0.2.3-2


This package wastes over 800MiB of rebase space, I assume by reserving
COMMON arrays of about 200MiB across four octave object files.  Could
you please check if that's really necessary?  As it stands now, you
really _dont_ want to install that package on a 32bit Cygwin, as it is
almost certain to break something else.


Regards,
Achim.



I will look again
http://savannah.gnu.org/bugs/?func=detailitem_id=47761

It is a bug from the upstream code.
http://www.mpipks-dresden.mpg.de/~tisean/Tisean_3.0.1/index.html

I tried to patch it last year but I was not successful,
I will look again.

Regards
Marco




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

Re: TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Marco Atzeri 

On 04/02/2017 15:13, Patrick Knight wrote:

What is the link to download the test release please?

Thanks,

Patrick Knight


Use setup to install it.
At the "select packages" window select test on
the upper left.
Pay attention to the other tests packages available

Regards
Marco

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Corinna Vinschen 
On Feb  4 15:56, Houder wrote:
> On Sat, 4 Feb 2017 14:00:15, Corinna Vinschen wrote:
> [snip]
> 
> > Bug Fixes
> > -
> > - Fix handling of Alt-Numpad sequences in console handler.
> >   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00135.html
> > 
> > - Fix erasing UTF-8 multibyte characters in cooked mode.
> >   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00299.html
> 
> To be "comsumed" on Monday ...
> 
> Hi Corinna,
> 
> This time I decided to test with alt-1 and alt-254 as input ... Output is not
> as expected, I would say ...
> 
> R. Henri
> 
> =
> Using the Windows Console (cp437):
> 
> 64 LANG = en_US.UTF-8, LC_ALL =
> => LANG = en_US.UTF-8
> /home/corinna/src/cygwin/cygwin-2.7.0/cygwin-2.7.0-0.2.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc
> 64-@@ cygcheck -sv | awk '$1 ~ /^(bash|libreadline.|cygwin|"cygwin1.dll")$/'
>   "cygwin1.dll" v0.0 ts=2017-02-03 21:17
> bash4.4.12-3 OK
> cygwin  2.7.0-0.2OK
> libreadline77.0.1-1  OK
> 
> # enter alt-1, followed by lf
> 64-@@ ☺
> bash: ☺: command not found
> # enter alt-254, followed by lf
> 64-@@ [G■ < expected one character ...
> bash: [G■: command not found
> # enter alt-254, followed by 3 bs, followed by lf
> 64-@@ < no problem
> 
> 64-@@ bash --noediting # disable readline
> => LANG = en_US.UTF-8
> 
> # enter alt-254, followed by 3 bs, followed by lf
> 64-@@
> bash: $'\E\E': command not found < knock, knock, who is this?
> 
> # enter alt-254, followed by 3 bs, followd by '| od', followed by lf
> 64-@@ echo | od -tx1z
> 000 1b 1b 0a >...<
> 003
> 64-@@ exit
> exit
> 
> 64-@@ dash
> # enter alt-1 followed by lf
> $ ☺
> dash: 1: ☺: not found
> 
> # enter alt-1, followed by bs, followed by lf
> $ < no problem
> 
> # enter alt-254, followed by lf
> $ [G■
> dash: 3: [G■: not found

Works fine for me in dash as well as in od in a console with cp437:

  $ od -tx1
  <^J><^D>
  ☺
  000 e2 98 ba 0a
  004
  $ od -tx1
  <^J><^D>
  000 0a
  001
  $ od -tx1
  <^J><^D>
  ■
  000 e2 96 a0 0a
  004
  $ od -tx1
  <^J><^D>
  000 0a
  001


Corinna

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


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

2017-02-04 Thread Achim Gratz 
Thomas Wolff writes:
> I have uploaded mintty 2.7.4 with the following changes:

Since about November/December last year I'm having problems with screen
and tmux sessions in mintty not correctly refreshing and leaving garbage
characters displayed in the terminal.  It seems that the terminal size
is not always correctly reported, especially if you make the window
occupy the left or right half of the screen via Windows shortcut.

Additionally, there seems to be an off-by-one bug when the last line of
the terminal needs to be scrolled up in order to show content that is
longer than the remaining width.  This happens when you for instance
recall a long command from history.  It's hard to see what exactoly
happens, but it looks like the one character too many gets printed (and
wraps onto the next line) before the whole terminal window gest scrolled
up and the rest of the command gets printed in the line below the
single wrapped character.  That remainder is in various states of
disarray, showing both remnants from the original prompt on the last
line (now three lines up), empty /spaces where there should have been
characters from the command and then of course parts of the command.

I'm not seeing these problems when I'm working via konsole from a
Linux box.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

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

Re: cppcheck 1.77 Segmentation fault (64-bit)

2017-02-04 Thread David Stacey 

On 04/02/17 00:08, David Stacey wrote:

On 29/01/17 21:04, Jim Reisert AD1C wrote:

Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0.  Even uninstalling gcc 6.0 does not fix the
problem.  I had to create an entirely new Cygwin-64 environment to get
past the problem.

I invite you (Dave) to try the experiment yourself.  You would be wise
to back up your Cygwin environment before doing this.


I've spent a little time looking into this. As per the stack track you 
supplied, cppcheck is falling over constructing a std::istringstream 
with a string passed in to initialise the stream. I'll need to debug 
this into the STL to work out exactly why the seg fault is occurring.


I'm stuck here, I'm afraid. From what I can deduce, cppcheck is using 
the explicitly instantiated version of std::istringstream in libstdc++, 
but my gdb-foo isn't good enough to work out what's going on past that.


I've taken a good look at the cppcheck code, and I believe that it's 
using the STL correctly. If I'm being picky, cppcheck assumes that the 
std::istringsteam is going to construct successfully, i.e. there doesn't 
seem to be a 'catch' exception handler. But given the small size of the 
strings we're dealing with, it's not too unreasonable to expect the 
string copy to succeed.


Anyway, my assumption at the moment is that this is an issue with libstdc++.

Any thoughts?

Dave.


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

Re: [ANNOUNCEMENT] Updated: octave forge packages

2017-02-04 Thread Achim Gratz 
Marco Atzeri writes:
> octave-tisean0.2.3-2

This package wastes over 800MiB of rebase space, I assume by reserving
COMMON arrays of about 200MiB across four octave object files.  Could
you please check if that's really necessary?  As it stands now, you
really _dont_ want to install that package on a 32bit Cygwin, as it is
almost certain to break something else.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Houder 
On Sat, 4 Feb 2017 14:00:15, Corinna Vinschen wrote:
[snip]

> Bug Fixes
> -
> - Fix handling of Alt-Numpad sequences in console handler.
>   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00135.html
> 
> - Fix erasing UTF-8 multibyte characters in cooked mode.
>   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00299.html

To be "comsumed" on Monday ...

Hi Corinna,

This time I decided to test with alt-1 and alt-254 as input ... Output is not
as expected, I would say ...

R. Henri

=
Using the Windows Console (cp437):

64 LANG = en_US.UTF-8, LC_ALL =
=> LANG = en_US.UTF-8
/home/corinna/src/cygwin/cygwin-2.7.0/cygwin-2.7.0-0.2.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc
64-@@ cygcheck -sv | awk '$1 ~ /^(bash|libreadline.|cygwin|"cygwin1.dll")$/'
  "cygwin1.dll" v0.0 ts=2017-02-03 21:17
bash4.4.12-3 OK
cygwin  2.7.0-0.2OK
libreadline77.0.1-1  OK

# enter alt-1, followed by lf
64-@@ ☺
bash: ☺: command not found
# enter alt-254, followed by lf
64-@@ [G■ < expected one character ...
bash: [G■: command not found
# enter alt-254, followed by 3 bs, followed by lf
64-@@ < no problem

64-@@ bash --noediting # disable readline
=> LANG = en_US.UTF-8

# enter alt-254, followed by 3 bs, followed by lf
64-@@
bash: $'\E\E': command not found < knock, knock, who is this?

# enter alt-254, followed by 3 bs, followd by '| od', followed by lf
64-@@ echo | od -tx1z
000 1b 1b 0a >...<
003
64-@@ exit
exit

64-@@ dash
# enter alt-1 followed by lf
$ ☺
dash: 1: ☺: not found

# enter alt-1, followed by bs, followed by lf
$ < no problem

# enter alt-254, followed by lf
$ [G■
dash: 3: [G■: not found

# enter alt-254, followed by 3 bs, followd by '| od', followed by lf
$
dash: 4: : not found < euh, what?

# enter alt-254, followed by 3 bs, followd by '| od', followed by lf
$ echo | od -tx1z
000 1b 1b 0a >...<
003

# enter alt-254, followed by '| od', followed by lf
$ echo [G■ | od -tx1z
000 1b 1b 5b 47 e2 96 a0 0a  >..[G<
010
# euh ... e2 96 a0 is utf-8 for u25a0, but I cannot explain 1b 1b
# at the front (and 5b 47, i.e. { G)

# enter alt-148, followed by lf
$ ö
dash: 7: ö: not found

# enter alt-148, followed by bs, followd by lf
$
$ < no problem

=


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

Re: Is it OK to mount cygdrive on / ?

2017-02-04 Thread Andrey Repin 
Greetings, Rustam!

> I've added an extra / mountpoint in /etc/fstab in order to be able to
> access C: without /cygdrive like this:

> none /cygdrive cygdrive binary,posix=0,user 0 0
> none / cygdrive binary,posix=0,user 0 0

Only one cygdrive mount is effective.

> It seems to work, I can access the C: drive with just /c.

> But normally an "ls /cygdrive" should list the drives, whereas "ls /"
> lists the contents of the Cygwin root. So it seems there are now two
> root mountpoints overlaying each other.

> So I was wondering if my approach is if this is technically undefined
> behavior and might conceivably break something or is it OK (less the
> drive listing limitation mentioned above).

Undefined behavior, but only because you're using two mount entries at once.
Accessing drive letters directly from inside Cygwin is often considered a grey 
area.
Too much may happen on this border. You have to clearly understand, how Cygwin
interact with other system, to avoid issues.
If you want to access Windows path, recommended route lies through the use of
cygpath utility to convert native paths to the Cygwin scheme. Et vice versa.


-- 
With best regards,
Andrey Repin
Saturday, February 4, 2017 17:17:15

Sorry for my terrible english...


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

Re: TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Patrick Knight 
What is the link to download the test release please?

Thanks,

Patrick Knight
Security Research Architect
http://www.cylance.com
561.768.9466 (Office)
561.427.4246 (Mobile)

On 2/4/17, 8:00 AM, "cygwin-announce-ow...@cygwin.com on behalf of Corinna 
Vinschen"  wrote:

Hi folks,


I uploaded a new Cygwin test release 2.7.0-0.2

This is the same as 2.7.0-0.1 just with additional patch to speed
up socket connections in certain scenarios.

This is most likely what I'll release next week.

===

What's new:
---

- Support for /proc//environ.

- New API: getentropy, getrandom, NL_LOCALE_NAME.


What changed:
-


Bug Fixes
-

- Fix rename(2) fail with EACCES if newfile is in use.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00108.html

- Always try to write all incoming bytes to blocking pipes, as required
  by POSIX.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00087.html

- Fix handling of Alt-Numpad sequences in console handler.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00135.html

- Fix erasing UTF-8 multibyte characters in cooked mode.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00299.html

- Fix handling of a literal '+' by cygcheck -p
  Addresses:  https://cygwin.com/ml/cygwin/2014-01/msg00287.html

- Fix limited Internet speeds caused by inappropriate socket buffering.
  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html

===

Please test.


Thanks,
Corinna

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

TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Corinna Vinschen 
Hi folks,


I uploaded a new Cygwin test release 2.7.0-0.2

This is the same as 2.7.0-0.1 just with additional patch to speed
up socket connections in certain scenarios.

This is most likely what I'll release next week.

===

What's new:
---

- Support for /proc//environ.

- New API: getentropy, getrandom, NL_LOCALE_NAME.


What changed:
-


Bug Fixes
-

- Fix rename(2) fail with EACCES if newfile is in use.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00108.html

- Always try to write all incoming bytes to blocking pipes, as required
  by POSIX.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00087.html

- Fix handling of Alt-Numpad sequences in console handler.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00135.html

- Fix erasing UTF-8 multibyte characters in cooked mode.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00299.html

- Fix handling of a literal '+' by cygcheck -p
  Addresses:  https://cygwin.com/ml/cygwin/2014-01/msg00287.html

- Fix limited Internet speeds caused by inappropriate socket buffering.
  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html

===

Please test.


Thanks,
Corinna

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

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.2

2017-02-04 Thread Corinna Vinschen 
Hi folks,


I uploaded a new Cygwin test release 2.7.0-0.2

This is the same as 2.7.0-0.1 just with additional patch to speed
up socket connections in certain scenarios.

This is most likely what I'll release next week.

===

What's new:
---

- Support for /proc//environ.

- New API: getentropy, getrandom, NL_LOCALE_NAME.


What changed:
-


Bug Fixes
-

- Fix rename(2) fail with EACCES if newfile is in use.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00108.html

- Always try to write all incoming bytes to blocking pipes, as required
  by POSIX.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00087.html

- Fix handling of Alt-Numpad sequences in console handler.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00135.html

- Fix erasing UTF-8 multibyte characters in cooked mode.
  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00299.html

- Fix handling of a literal '+' by cygcheck -p
  Addresses:  https://cygwin.com/ml/cygwin/2014-01/msg00287.html

- Fix limited Internet speeds caused by inappropriate socket buffering.
  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html

===

Please test.


Thanks,
Corinna

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

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