[ANNOUNCEMENT] gsl 1.16-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gsl-1.16-2
* libgsl0-1.16-2
* libgsl-devel-1.16-2

the GNU Scientific Library, a collection of numerical routines for 
scientific computing. The library provides a wide range of mathematical 
routines such as random number generators, special functions and 
least-squares fitting.

This release rearranges the subpackages into a more conventional layout, 
and adds a patch for an issue with sorting complex numbers:

https://savannah.gnu.org/bugs/?39055

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

[ANNOUNCEMENT] tigervnc 1.5.0-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* tigervnc-1.5.0-2
* tigervnc-server-1.5.0-2
* tigervnc-server-module-1.5.0-2

TigerVNC is a high-performance implementation of VNC, a client/server 
application that allows users to launch and interact with graphical 
applications on remote machines. TigerVNC provides the levels of 
performance necessary to run 3D and video applications, and it attempts 
to maintain a common look and feel and re-use components, where 
possible, across the various platforms that it supports. TigerVNC also 
provides extensions for advanced authentication methods and TLS 
encryption.

Please note that, like other Cygwin graphical applications, these 
packages are X11-based.  That means the client requires a running X 
server in order to start, and the server will allow accessing X programs 
or even entire X sessions remotely but not your Windows desktop.

This release has been rebuilt with xorg-server 1.17.4 sources.

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

tigervnc 1.5.0-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* tigervnc-1.5.0-2
* tigervnc-server-1.5.0-2
* tigervnc-server-module-1.5.0-2

TigerVNC is a high-performance implementation of VNC, a client/server 
application that allows users to launch and interact with graphical 
applications on remote machines. TigerVNC provides the levels of 
performance necessary to run 3D and video applications, and it attempts 
to maintain a common look and feel and re-use components, where 
possible, across the various platforms that it supports. TigerVNC also 
provides extensions for advanced authentication methods and TLS 
encryption.

Please note that, like other Cygwin graphical applications, these 
packages are X11-based.  That means the client requires a running X 
server in order to start, and the server will allow accessing X programs 
or even entire X sessions remotely but not your Windows desktop.

This release has been rebuilt with xorg-server 1.17.4 sources.

gsl 1.16-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gsl-1.16-2
* libgsl0-1.16-2
* libgsl-devel-1.16-2

the GNU Scientific Library, a collection of numerical routines for 
scientific computing. The library provides a wide range of mathematical 
routines such as random number generators, special functions and 
least-squares fitting.

This release rearranges the subpackages into a more conventional layout, 
and adds a patch for an issue with sorting complex numbers:

https://savannah.gnu.org/bugs/?39055

[ANNOUNCEMENT] libcdio 0.93-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* libcdio-0.93-2
* libcdio16-0.93-2
* libcdio++0-0.93-2
* libiso9660_10-0.93-2
* libiso9660++0-0.93-2
* libudf0-0.93-2
* libcdio-devel-0.93-2
* libcdio++-devel-0.93-2
* libcdio_cdda2-10.2+0.93+1-1
* libcdio_paranoia2-10.2+0.93+1-1
* libcdio_paranoia-devel-10.2+0.93+1-1
* cdparanoia-10.2+0.93+1-1

The libcdio package contains a library which encapsulates CD-ROM reading 
and control. Applications wishing to be oblivious of the OS- and 
device-dependent properties of a CD-ROM can use this library. Also 
included is a library for working with ISO-9660 filesystems. Some 
support for disk image types like CDRWin's BIN/CUE format, cdrdao's TOC 
format, and Nero's NRG format are available. Therefore, applications 
that use this library also have the ability to read disc images as 
though they were CD's.

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

libcdio 0.93-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* libcdio-0.93-2
* libcdio16-0.93-2
* libcdio++0-0.93-2
* libiso9660_10-0.93-2
* libiso9660++0-0.93-2
* libudf0-0.93-2
* libcdio-devel-0.93-2
* libcdio++-devel-0.93-2
* libcdio_cdda2-10.2+0.93+1-1
* libcdio_paranoia2-10.2+0.93+1-1
* libcdio_paranoia-devel-10.2+0.93+1-1
* cdparanoia-10.2+0.93+1-1

The libcdio package contains a library which encapsulates CD-ROM reading 
and control. Applications wishing to be oblivious of the OS- and 
device-dependent properties of a CD-ROM can use this library. Also 
included is a library for working with ISO-9660 filesystems. Some 
support for disk image types like CDRWin's BIN/CUE format, cdrdao's TOC 
format, and Nero's NRG format are available. Therefore, applications 
that use this library also have the ability to read disc images as 
though they were CD's.

[ANNOUNCEMENT] gst123 0.3.3-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gst123-0.3.3-2

The program gst123 is designed to be a more flexible command line player 
in the spirit of ogg123, based on GStreamer. It plays all file formats 
GStreamer understands, so if you have a media collection which contains 
different file formats, you can use gst123 to play all your files.

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

krb5 1.13.2-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* krb5-workstation-1.13.2-2
* krb5-server-1.13.2-2
* krb5-server-ldap-1.13.2-2
* krb5-pkinit-1.13.2-2
* krb5-k5tls-1.13.2-2
* krb5-samples-1.13.2-2
* krb5-doc-1.13.2-2
* libgssapi_krb5_2-1.13.2-2
* libgssrpc4-1.13.2-2
* libk5crypto3-1.13.2-2
* libkadm5clnt_mit9-1.13.2-2
* libkadm5srv_mit9-1.13.2-2
* libkdb5_8-1.13.2-2
* libkrad0-1.13.2-2
* libkrb5_3-1.13.2-2
* libkrb5support0-1.13.2-2
* libkrb5-devel-1.13.2-2

This is the reference implementation of the Kerberos network authentication
protocol from MIT. It is designed to provide strong authentication for
client/server applications by using secret-key cryptography.

This release includes patches for CVE-2015-2695, CVE-2015-2696, and 
CVE-2015-2697.

[ANNOUNCEMENT] krb5 1.13.2-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* krb5-workstation-1.13.2-2
* krb5-server-1.13.2-2
* krb5-server-ldap-1.13.2-2
* krb5-pkinit-1.13.2-2
* krb5-k5tls-1.13.2-2
* krb5-samples-1.13.2-2
* krb5-doc-1.13.2-2
* libgssapi_krb5_2-1.13.2-2
* libgssrpc4-1.13.2-2
* libk5crypto3-1.13.2-2
* libkadm5clnt_mit9-1.13.2-2
* libkadm5srv_mit9-1.13.2-2
* libkdb5_8-1.13.2-2
* libkrad0-1.13.2-2
* libkrb5_3-1.13.2-2
* libkrb5support0-1.13.2-2
* libkrb5-devel-1.13.2-2

This is the reference implementation of the Kerberos network authentication
protocol from MIT. It is designed to provide strong authentication for
client/server applications by using secret-key cryptography.

This release includes patches for CVE-2015-2695, CVE-2015-2696, and 
CVE-2015-2697.

--
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: pthread_kill: signals remain pending after target thread exits

[Corinna Vinschen]

On Nov  2 23:54, John Carey wrote:
> > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > Sent: Monday, November 02, 2015 9:58 AM
> > On Nov  2 15:18, Corinna Vinschen wrote:
> > > On Oct 29 16:16, John Carey wrote:
> > > > > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > > > > Sent: Thursday, October 29, 2015 1:02 AM
> > > > > On Oct 28 10:14, Corinna Vinschen wrote:
> > > > ...
> > > > > > > Thanks; that was fast!  I tried replacing cygwin1.dll with 
> > > > > > > cygwin1-20151023.dll .
> > > > > > >
> > > > > > > The original test case now works.  I checked some of my other 
> > > > > > > tests,
> > > > > > > and unfortunately some of them failed, so I extracted out a new 
> > > > > > > test
> > > > > > > case, which is attached.  My guess is that something is subtly 
> > > > > > > different
> > > > > > > about the timing on this test.
> > > > > >
> > > > > > Is this a regression?  Did it work with 2.2.1?
> > > > >
> > > > > Answering myself here, this didn't work at all in 2.2.1.  I can
> > > > > reproduce the problem and I'm going to take a look.  Not sure if
> > > > > there's a quick solution, though.  This looks like a deadlock
> > > > > situation.  The signal definitely got send, I just don't see yet
> > > > > why it's not handled in wait_sig.
> > > >
> > > > Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
> > > > differ: there is no Cygwin process left hanging that cannot be
> > > > killed by a Cygwin signal.
> > > >
> > > > But both tests appear to pass in Cygwin 1.7.9, so in that sense
> > > > it is a regression, just not a recent one.
> > >
> > > The regression here was my original fix.  It didn't clear pending
> > > signals for an exiting thread thorougly enough.  I applied a patch now
> > > which should fix this issue.  I'll upload a new developer snapshot to
> > > https://cygwin.com/snapshots/ later today or tomorrow (still looking
> > > into the PrlFS issue).  Please give it a try.
> > 
> > Snapshot is up.  The fix is in the 2.3.0-0.5 test release as well.
> > Please give any one of them a try.
> 
> I tested snapshot cygwin1-20151102.dll, and it works in all of my tests.  
> Nice!

One good news, thanks!

> I'm glad you figured out how to delete those pending signals.

Given that I introduced the regression in the first place, it's a bit
embarrassing that it took me so long to understand it 8-}


Corinna

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


pgpnsP3HTlyfY.pgp
Description: PGP signature

gst123 0.3.3-2

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* gst123-0.3.3-2

The program gst123 is designed to be a more flexible command line player 
in the spirit of ogg123, based on GStreamer. It plays all file formats 
GStreamer understands, so if you have a media collection which contains 
different file formats, you can use gst123 to play all your files.

Re: Pop up GUI remotely via SSH

[trimat]

If I create the service with the command /ssh-host-config/ (and then set up
user and privileges) I can start remotely from SSH a program without the
possibility to see its GUI.

If I modify the /sshd/ service by Windows Services logging on as "Local
System account" with "Allow service to interact with desktop" option
enabled, I get an error: "The CYGWIN sshd service on Local Computer started
and then stopped. Some services stop automatically if they are not in use by
other services or programs".

Moreover, it doesn't start even if I create the service with the command
/cygrunsrv -I sshd --interactive -d "CYGWIN sshd" -p
"C:\APPS\CYGWIN\bin\cygrunsrv.exe" -a -D -e "CYGWIN=ntsec tty" -y tcpip/.

I am not aware of Xserver, how can I check this?
Thanks



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Pop-up-GUI-remotely-via-SSH-tp122269p122540.html
Sent from the Cygwin list mailing list archive at Nabble.com.

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

iso-codes 3.63-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* iso-codes-3.63-1

This package aims to provide the list of the ISO country, language,
and currency names and their translations in one place.

This is an update to the latest upstream release:

https://anonscm.debian.org/cgit/pkg-isocodes/iso-codes.git/tree/ChangeLog

[ANNOUNCEMENT] iso-codes 3.63-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* iso-codes-3.63-1

This package aims to provide the list of the ISO country, language,
and currency names and their translations in one place.

This is an update to the latest upstream release:

https://anonscm.debian.org/cgit/pkg-isocodes/iso-codes.git/tree/ChangeLog

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

Cygwin64 vs. Cygwin (speed)

[Jim Reisert AD1C]

In another thread, I wrote (and Corinna replied):

>> I have tried 64-bit Cygwin in the past.  I do a lot of file I/O and
>> sorting/searching on largish test-based data sets, and 64-bit was
>> noticeably slower than 32-bit Cygwin,
>
> Hmm, I usually have the opposite impression...

I'm using malloc/calloc, is there a different memory allocator I
should be using for Cygwin64?

Thanks - Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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: TP_NUM_C_BUFS too small

[Corinna Vinschen]

On Nov  3 00:07, Helmut Karlowski wrote:
> Am 02.11.2015, 12:15 Uhr, schrieb Corinna Vinschen:
> 
> >>Glad it's fixed!  For the record, could you say what sort of bug would
> >>cause
> >>a fatal internal error like that?
> >>Just curious,
> >
> >Me too.  Sounds like some kind of recursion.
> 
> It all happened after I had replaced all strcpy/strcat by strlcpy like this:
> 
> strcpy(t,s) -> pos = strlcpy(t,s,size)
> strcat(t,s) -> pos += strlcpy(t+pos,s,size-pos)
> 
> At some point the pos-parameter was wrong and the resulting string became
> something undesired. And that string probably was passed to fopen, maybe pos
> became very large way beyond the boundaries of the string which is from the
> stack.
> 
> It's hard to reproduce what happened in a simple case, and I was in some
> hurry then, but I saved the strace-output:
> [...]
> fhandler_base::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
>41 4266380 [main] ue 460 fhandler_base::open_fs: 1 =
> fhandler_disk_file::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x8000)
>34 4266414 [main] ue 460 open: 3 = open(u, 0x8000)
>   186 4266600 [main] ue 460 _cygwin_istext_for_stdio: fd 3: opened as binary
>   232 4266832 [main] ue 460 close: close(3)
>32 4266864 [main] ue 460 fhandler_base::close: closing
> '/usr/src/ue314/bin/u' handle 0x170
>49 4266913 [main] ue 460 close: 0 = close(3)
>   460 4267373 [main] 20 460 open: open(u, 0x0)
   ^^
   !!

> This loops some 100 times, then:
> [...]
> 
> Note the process-name gets overwritten by a number of increasing length, the
> last being 254 bytes long before the process exits.

Yuk.

> Don't know if that's of any use. It crashed not only on cygwin.
> 
> BTW: Is there a documentation about the columns of the strace-output
> somewhere?

Uhm, I don't think so.  From left to right:

- usecs since last trace output

- usecs since process start

- [name of thread] (this only makes sense for the named threads,
  mainly the "main" thread, the "sig" thread, and a few short-lived
  helper threads in the DLL.  Pthreads don't have a name, they are called
  "unknown ($thread_id)"

- process name

- pid

- function/method name:

- last but not least the actual output string.


Thanks,
Corinna

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


pgppIeFafsbTW.pgp
Description: PGP signature

Re: Help: cygheap base mismatch detected

[Corinna Vinschen]

On Nov  2 18:24, Jim Reisert AD1C wrote:
> On Mon, Nov 2, 2015 at 4:31 AM, Corinna Vinschen wrote:
> 
> > It seems a Windows DLL or a virus scanner DLL gets loaded to this
> > address for some reason.  I'm a bit at a loss to make a suggestion here,
> > except for switching to 64 bit Cygwin which has much less problems with
> > this due to the huge address space.
> 
> I meant to reply to this earlier today, but lines between day/night
> and work/not have been too blurry lately.
> 
> I tried a clean install of 32-bit Cygwin, but that didn't fix
> anything.  So then on a lark, I rebooted the computer (turned it off
> actually, which I have not done in weeks), and magically, the problem
> went away.  Maybe Windows 10 had its knickers in a twist or something,
> but everything else seemed to run just fine, except Cygwin.

Probably something like I wrote in my previous reply.

> I have tried 64-bit Cygwin in the past.  I do a lot of file I/O and
> sorting/searching on largish test-based data sets, and 64-bit was
> noticeably slower than 32-bit Cygwin,

Hmm, I usually have the opposite impression...

> so I have not been gung-ho to
> switch.  Maybe now that it's more mature, I should give it another
> shot.


Corinna

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


pgpssuRrEyEpu.pgp
Description: PGP signature

Re: Using cp converts windows junctions to a cywin symlink

[Corinna Vinschen]

On Nov  2 13:57, Adrian H wrote:
> I was copying a directory of files, some of which were windows junctions.
> These got converted to a cygwin symlink.  Although I am impressed that there
> are such a thing for those OSs/drives that do not support such things, for 
> those
> that do, I think it would be good to keep the copy a junction.  Otherwise,
> things can get messy.
> 
> Can this be corrected?

No.  The actual copy is done by the application, not by Cygwin.  The
application (cp, rsync, whatnot) is a POSIX application which has no
notion of "junctions".  From the view of the POSIX application,
directory junctions are symlinks.  So the copying application will call
the symlink or symlinkat function.  This call has no idea that the
to-be-created symlink is a copy of a directory juntion.  After all,
there 's no connection between the stat call on the source and the
symlink call on the destination.

To alleviate this partially, you can copy with the environment variable
CYGWIN set to "winsymlinks:native" or "winsymlinks:nativestrict".  This
will create native symlinks, not directory junctions, so it requires the
"Create symbolic links" privilege set for the current user, but it's
better than nothing.  From a consumer perspective, a directory junction
and a symlink to a directory are not really different.


Corinna

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


pgpW_c9gQOvg6.pgp
Description: PGP signature

Re: fstat st_size on open files on Parallels filesystem is wrong

[Corinna Vinschen]

On Nov  2 17:05, Jonathan Lennox wrote:
> On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
> saying:
> 
> > On Nov  2 08:08, Jonathan Lennox wrote:
> > > On Monday, November 2 2015, "Corinna Vinschen" wrote to 
> > > "cygwin@cygwin.com" saying:
> > > > I added support for this filesystem (called prlfs in mount output) and
> > > > without hardlink support for now.  I uploaded a new developer snapshot
> > > > to https://cygwin.com/snapshots/ Please give it a try.
> > > 
> > > No, still seeing the failure in the snapshot:
> > > 
> > > $ ./stat-size-test.exe /cygdrive/y/foo ~/foo
> > > /cygdrive/y/foo: fstat: st_size=0
> > > /cygdrive/y/foo: stat: st_size=12
> > > /home/jonathan/foo: fstat: st_size=12
> > > /home/jonathan/foo: stat: st_size=12
> > 
> > Weird.  There should be no FileNetworkOpenInformation call anymore for
> > Netapp and the PrlSF filesystem.
> > 
> > Does Cygwin correctly recognize the FS?  What does `mount' print?  It
> > should print `type prlfs'.
> 
> $ mount
> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type iso9660 (binary,posix=0,user,noumount,auto)
> U: on /cygdrive/u type prlsf (binary,posix=0,user,noumount,auto)
> V: on /cygdrive/v type prlsf (binary,posix=0,user,noumount,auto)
> W: on /cygdrive/w type prlsf (binary,posix=0,user,noumount,auto)
> X: on /cygdrive/x type prlsf (binary,posix=0,user,noumount,auto)
> Y: on /cygdrive/y type prlsf (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type prlsf (binary,posix=0,user,noumount,auto)

"prlsf".  If Cygwin had recognized the FS, it would have printed
"prlfs".  I did this shuffle "sf" vs. "fs" on purpose.  But...

> > Can you please once again call `/usr/lib/csih/getVolInfo.exe Z:' and
> > `/usr/lib/csih/getVolInfo.exe Y:' and paste the output here?  I'm not
> > quite sure because the original getVolInfo call returned a filesystem
> > type of "PrlSF", not "PrlFS" as I had expected.  Cygwin now checks for
> > "PrlSF".
> > 
> 
> $ /usr/lib/csih/getVolInfo.exe /cygdrive/z
> Device Type: 7
> Characteristics: 10
> Volume Name: 
> Serial Number  : 0
> Max Filenamelength : 255
> Filesystemname : 
> Flags  : 3
> [...]

...I don't understand *why* Cygwin doesn't recognize the FS.  It checks
explicitely for the "PrlSF" filesystem name.  I tried this locally
by faking the above information and it worked for me.

Btw., there's more than one problem here.  The fact that all drives
have the same volume name *and* a serial number of 0 leads to all
drives being identified as the same drive.  I have to add some code
creating a reproducible serial number from scratch if the original
serial number is 0, but for testing, I didn't implement this yet.

Talking about testing.  I created a test DLL which provides a lot
of output when stracing the calls.  I'll send you a private mail
with the URL to this DLL in a minute.  Please install it, and under
that DLL, run

  $ strace -o stat.trace ./stat-size-test.exe /cygdrive/y/foo

I'll need to have a look into that strace to (hopefully) see what's
going wrong.

>   FILE_READ_ONLY_VOLUME   : FALSE
>   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>   FILE_SUPPORTS_TRANSACTIONS  : FALSE
> 
> (Note that the literal "/usr/lib/csih/getVolInfo.exe Z:" printed
> "NtOpenFile(\??\C:\cygwin64\home\jonathan\Z:) failed, c033", so I assume
> that's not what you want.)

Indeed. Sorry, I was thinking of one of my local test hacks using DOS
paths.


Corinna

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


pgpfFlveAq4fK.pgp
Description: PGP signature

Re: Mounting a network share

[Corinna Vinschen]

On Nov  2 12:06, Mike Brown wrote:
> On Mon, Nov 02, 2015 at 05:26:51PM +0100, Corinna Vinschen wrote:
> > On Nov  2 10:03, Mike Brown wrote:
> > > On Mon, Nov 02, 2015 at 04:40:33AM +0300, Andrey Repin wrote:
> > > > If you want to do it from Cygwin side, use fstab and don't use /cygdrive
> > > > prefix. It is for automatic mounts ONLY.
> > > 
> > > I went and found the Cygwin web page that describes fstab.  What it 
> > > doesn't
> > > say is how to use it.
> > 
> > It does: https://cygwin.com/cygwin-ug-net/using.html#mount-table
> 
> What I mean is that I was able to create an entry, but I have no idea how to
> get the mount program to read the contents.
> 
> > > I have the following entry:
> > > 
> > > 192.168.1.40:/Public /Public nfs noacl 0 0
> >   
> > 
> > This syntax isn't known in Windows.  Use the same syntax as with SMB
> > shares, just use forward slashes:
> > 
> >   //192.168.1.40/Public /Public foo binary 0 0
> > 
> > "noacl" has no meaning on NFS shares, btw. 
> 
> No there no explantion on how to enter a user and password.  I tried the nfs
> syntax because it doesn't require a password.

The Cygwin mount is no actual mount command because it doesn't mount
anything.  It's not an OS.  The mount point in Cygwin is just a
translation from DOS to POSIX path as outlined in the documentation.
The first field in fstab is basically the underlying Windows path, just
with forward slashes.  The *actual* mounting, as on Linux, has to be
done on the OS level.

If you have to attach to a remote drive with username and password, you
have to use `net use ...'.  In case of NFS mounts you can also
(preferredly) use the $SYSTEMROOT\\system32\\mount.exe command which is
part of the Windows NFS client installation.  Due to this executable
name clash between Cygwin mount(1) and NFS mount(1) command, you have to
call the latter typically with full path, e.g.

 $ /cygdrive/c/Windows/System32/mount -h

Alternatively, if the mount doesn't require a username/password because
the mapping is done in AD or some RFC2307 service(*), just use the
SMB-like path (even for NFS) in the Cygwin mount table:

 //server/share /cygwin-path foo binary 0 0


HTH,
Corinna


(*) There's also a way to map the anonymous account to a certain
uid/gid value using a registry entry:

http://blogs.msdn.com/b/sfu/archive/2009/03/27/can-i-set-up-user-name-mapping-in-windows-vista.aspx

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


pgpWivIQ1nnks.pgp
Description: PGP signature

Re: Cygwin64 vs. Cygwin (speed)

[Corinna Vinschen]

On Nov  3 07:59, Jim Reisert AD1C wrote:
> In another thread, I wrote (and Corinna replied):
> 
> >> I have tried 64-bit Cygwin in the past.  I do a lot of file I/O and
> >> sorting/searching on largish test-based data sets, and 64-bit was
> >> noticeably slower than 32-bit Cygwin,
> >
> > Hmm, I usually have the opposite impression...
> 
> I'm using malloc/calloc, is there a different memory allocator I
> should be using for Cygwin64?

There is none.  While Cygwin's malloc is slow in multi-threading
scenarios due to dumb locking (which I really hope to fix at one point),
it shouldn't be any slower on 64 bit compared to 32 bit.


Corinna

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


pgp2UhF3Hkgjh.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.5

[Corinna Vinschen]

On Nov  3 11:56, Ken Brown wrote:
> On 11/2/2015 11:39 AM, Corinna Vinschen wrote:
> >Hi Cygwin friends and users,
> >
> >
> >I released a new TEST version of Cygwin, 2.3.0-0.5.
> 
> I tried to build cygport with this release of Cygwin installed, and I found
> that a call to aclocal seemed to hang (or infloop?), with high CPU usage.
> This is on Windows 10, with both 32-bit and 64-bit Cygwin.  The problem
> doesn't occur with 2.3.0-0.4.
> 
> To reproduce:
> 
> git clone  git://github.com/cygwinports/cygport.git
> cd cygport
> ./autogen.sh

Yeah.  Immediately reproducible.  What a STUPID mistake in my code.
Expect a 2.3.0-0.6 soon.


Thanks for the report,
Corinna

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


pgpXaybk1fw7V.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.5

[Ken Brown]

On 11/2/2015 11:39 AM, Corinna Vinschen wrote:

Hi Cygwin friends and users,


I released a new TEST version of Cygwin, 2.3.0-0.5.


I tried to build cygport with this release of Cygwin installed, and I 
found that a call to aclocal seemed to hang (or infloop?), with high CPU 
usage.  This is on Windows 10, with both 32-bit and 64-bit Cygwin.  The 
problem doesn't occur with 2.3.0-0.4.


To reproduce:

git clone  git://github.com/cygwinports/cygport.git
cd cygport
./autogen.sh

Ken

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

[newlib-cygwin/cygwin-acl] Fix potential endless loop in pending_signals::clear

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=179415a9d7d473bbba17744abc7769db0f6462e8

commit 179415a9d7d473bbba17744abc7769db0f6462e8
Author: Corinna Vinschen 
Date:   Tue Nov 3 18:25:23 2015 +0100

Fix potential endless loop in pending_signals::clear

* sigproc.cc (pending_signals::clear): Fix previous fix resulting in
yet another endless loop.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/ChangeLog  |  5 +
 winsup/cygwin/sigproc.cc | 13 -
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index e7dc642..b6e7255 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,8 @@
+2015-11-03  Corinna Vinschen  
+
+   * sigproc.cc (pending_signals::clear): Fix previous fix resulting in
+   yet another endless loop.
+
 2015-11-02  Corinna Vinschen  
 
* include/netinet/ip.h (MAX_IPOPTLEN): Define.
diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
index fbc738d..6a7708f 100644
--- a/winsup/cygwin/sigproc.cc
+++ b/winsup/cygwin/sigproc.cc
@@ -402,16 +402,11 @@ sig_clear (int sig)
 void
 pending_signals::clear (_cygtls *tls)
 {
-  sigpacket *q = , *qnext;
+  sigpacket *q, *qnext;
 
-  while ((qnext = q->next))
-{
-  if (qnext->sigtls == tls)
-   {
- q->next = qnext->next;
- qnext->si.si_signo = 0;
-   }
-}
+  for (q =  (qnext = q->next); q->next = qnext->next)
+if (qnext->sigtls == tls)
+  qnext->si.si_signo = 0;
 }
 
 /* Clear pending signals of specific thread.  Called from _cygtls::remove */

[newlib-cygwin] Fix potential endless loop in pending_signals::clear

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=0ed1523470ba33a2afba1510a19e51c4af9e329a

commit 0ed1523470ba33a2afba1510a19e51c4af9e329a
Author: Corinna Vinschen 
Date:   Tue Nov 3 18:25:23 2015 +0100

Fix potential endless loop in pending_signals::clear

* sigproc.cc (pending_signals::clear): Fix previous fix resulting in
yet another endless loop.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/ChangeLog  |  5 +
 winsup/cygwin/sigproc.cc | 13 -
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index dfeaf39..b990d9f 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,8 @@
+2015-11-03  Corinna Vinschen  
+
+   * sigproc.cc (pending_signals::clear): Fix previous fix resulting in
+   yet another endless loop.
+
 2015-11-02  Corinna Vinschen  
 
* include/netinet/ip.h (MAX_IPOPTLEN): Define.
diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
index fbc738d..6a7708f 100644
--- a/winsup/cygwin/sigproc.cc
+++ b/winsup/cygwin/sigproc.cc
@@ -402,16 +402,11 @@ sig_clear (int sig)
 void
 pending_signals::clear (_cygtls *tls)
 {
-  sigpacket *q = , *qnext;
+  sigpacket *q, *qnext;
 
-  while ((qnext = q->next))
-{
-  if (qnext->sigtls == tls)
-   {
- q->next = qnext->next;
- qnext->si.si_signo = 0;
-   }
-}
+  for (q =  (qnext = q->next); q->next = qnext->next)
+if (qnext->sigtls == tls)
+  qnext->si.si_signo = 0;
 }
 
 /* Clear pending signals of specific thread.  Called from _cygtls::remove */

[ANNOUNCEMENT] Updated: mintty 2.2.1

[Thomas Wolff]

I have uploaded mintty 2.2.1 with the following changes:

Major New Search Feature (thanks to Kai (twitter:@sixhundredns)):
  * Search scrollback buffer (#85); shortcuts Alt+F3 or Shift+Ctrl+H; 
configuration options.


Window placement and Multi-Monitor support:
  * Option -p @N to select monitor (#288).
  * Interactive feature to tweak Alt+F2 to select monitor.
  * Options -p right and -p bottom to align window position (#288).
  * Option -s accepts special values "maxwidth" or "maxheight" (#171).
  * Per-monitor DPI support (#470, thanks to Takashi Kawasaki).
  * Fixed initial terminal size if reduced border is specified (#7).
  * Trying to enforce initial focus (#57).
  * New option ZoomFontWithWindow to disable Shift-coupled 
font-with-window zooming (#476).

  * Accepting xterm-compatible syntax in size parameter, like -s 80x24.

Keyboard input:
  * Supporting layout-specified key input for all cases (#483, thanks 
to maxime1986).

  * Combining accented characters that are not supported by Windows (#484).
  * Application control key mode (#405).
  * Tweaked/disabled shift-coupled window-with-font zooming on some 
keys; thus:

  * Reenabled Ctrl+_ (if _ is Shift+- on keyboard layout).
  * Avoiding inadvertent window-with-font zooming if "+" is a shifted key.

Bold attribute handling:
  * Tweaked smart brightening (for BoldAsColour), considering contrast 
to both normal colour and background.

  * Support BoldAsColour without BoldAsFont for plain text (#468).
  * New option BoldColour (#468, #478).
  * Not enforcing bold-overstriking if bold colour explicitly redefined 
(#468, #478).
  * New xterm OSC sequences (5;0;rgb/105;0) to define/reset colour for 
bold attribute (#468).


Other terminal features:
  * Fixed character operations beyond terminal width (#480).
  * Supporting X11 color names for colour specifications in OSC sequences.
  * Supporting xterm sequences to maximize window 
vertically/horizontally (#394).
  * New private OSC sequence to copy the window title to the clipboard 
(#303).


Configuration:
  * Changed action buttons in Options dialog; Apply does not save changes.
  * Added some Options menu configuration items (for previously 
introduced new options, thanks for the pattern to James Darnley #384).
  * New option -C to load additional configuration file without saving 
to it, particularly for use with colour schemes.

  * Supporting X11 color names for colour specifications in options.
  * New option -R to report window geometry on exit (~#477).
  * Optional Windows taskbar integration (#471, thanks to Johannes 
Schindelin).

  * Not inhibiting size options in nested invocation from Alt+F2.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

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

Updated: mintty 2.2.1

[Thomas Wolff]

I have uploaded mintty 2.2.1 with the following changes:

Major New Search Feature (thanks to Kai (twitter:@sixhundredns)):
  * Search scrollback buffer (#85); shortcuts Alt+F3 or Shift+Ctrl+H; 
configuration options.


Window placement and Multi-Monitor support:
  * Option -p @N to select monitor (#288).
  * Interactive feature to tweak Alt+F2 to select monitor.
  * Options -p right and -p bottom to align window position (#288).
  * Option -s accepts special values "maxwidth" or "maxheight" (#171).
  * Per-monitor DPI support (#470, thanks to Takashi Kawasaki).
  * Fixed initial terminal size if reduced border is specified (#7).
  * Trying to enforce initial focus (#57).
  * New option ZoomFontWithWindow to disable Shift-coupled 
font-with-window zooming (#476).

  * Accepting xterm-compatible syntax in size parameter, like -s 80x24.

Keyboard input:
  * Supporting layout-specified key input for all cases (#483, thanks 
to maxime1986).

  * Combining accented characters that are not supported by Windows (#484).
  * Application control key mode (#405).
  * Tweaked/disabled shift-coupled window-with-font zooming on some 
keys; thus:

  * Reenabled Ctrl+_ (if _ is Shift+- on keyboard layout).
  * Avoiding inadvertent window-with-font zooming if "+" is a shifted key.

Bold attribute handling:
  * Tweaked smart brightening (for BoldAsColour), considering contrast 
to both normal colour and background.

  * Support BoldAsColour without BoldAsFont for plain text (#468).
  * New option BoldColour (#468, #478).
  * Not enforcing bold-overstriking if bold colour explicitly redefined 
(#468, #478).
  * New xterm OSC sequences (5;0;rgb/105;0) to define/reset colour for 
bold attribute (#468).


Other terminal features:
  * Fixed character operations beyond terminal width (#480).
  * Supporting X11 color names for colour specifications in OSC sequences.
  * Supporting xterm sequences to maximize window 
vertically/horizontally (#394).
  * New private OSC sequence to copy the window title to the clipboard 
(#303).


Configuration:
  * Changed action buttons in Options dialog; Apply does not save changes.
  * Added some Options menu configuration items (for previously 
introduced new options, thanks for the pattern to James Darnley #384).
  * New option -C to load additional configuration file without saving 
to it, particularly for use with colour schemes.

  * Supporting X11 color names for colour specifications in options.
  * New option -R to report window geometry on exit (~#477).
  * Optional Windows taskbar integration (#471, thanks to Johannes 
Schindelin).

  * Not inhibiting size options in nested invocation from Alt+F2.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

Personal use not permitted: (was Re: Pop up GUI remotely via SSH)

[Linda Walsh]

trimat wrote:

If I create the service with the command /ssh-host-config/ (and
then set up user and privileges) I can start remotely from SSH
a program without the possibility to see its GUI.




Where are you expecting the output to come out?  Where it is
executing or where you ran ssh from?  Windows can't do the latter,
it can only do the former, and then only if you get all the security
tokens setup right (never have done it).  They used to have problems
where people would start programs from remote machines and popup
output on a remote PC, and people on the remote PC would respond to
it thinking it was a local system message (when it was really
a remote cracker trying to get their password).



If I modify the /sshd/ service by Windows Services logging on as
"Local System account" with "Allow service to interact with
desktop" option enabled, I get an error: "The CYGWIN sshd service
on Local Computer started and then stopped. Some services stop
automatically if they are not in use by other services or
programs".


---

Similar problem as above.  You can't forward remote output of
individual Windows programs.  You could try to start
a remote-desktop session -- and those have the ability to run
programs on startup that will have their output go to the person who
ran remote desktop, but what you seem to be asking for is like when
I "ssh" into a linux box and start 'gvim', it runs 'gvim' and
displays it on my local cygwin box.

That is all premised on ssh automatically forwarding any attempts
to access the remote X-server to your local box, where they will try
to contact your local X-server.


I am not aware of Xserver, how can I check this?


---

Read up on 'X11' on the web/google.  It is the main way unix/linux
boxes run programs remotely and have the output displayed locally.
If you know nothing about 'X', or how output from 'ssh' run programs
is forwarded through an encrypted connection back to your machine to
connect to the X-server (called Xwin.exe on cygwin), then you need
to learn alot more about what you are attempting to do -- much more
than I can relate in a "short" email.

Windows was designed around a 1 person/computer system, with
allowances for more than 1 person with the server editions of
windows.  If someone is logged into a windows PC (non-server
edition), you cannot log into it with remote-desktop, for example,
without it either blocking you (because someone is already using the
"1" Windows output channel), or "2" forcing the remote user to
log-out -- which can then allow you to create a 'remote desktop
session' where the remote pc's desktop is forwarded to you.

If you had a server and used "thin-clients" that would only be
used for keyboard and display (no local processing), MS didn't want
you to be able to grab the 100-cheap clients and all log into the
powerful server and share applications (like all of them running
their own version of WORD) -- because, instead, they wanted to sell
100-copies of Windows and
100 copies of WORD - even if only 1-5 out of 100 would use WORD at
any point in time.  They compromised on server editions by allowing
people to by "seats", which allow a "small", fixed number of users
to run an application (or to access the server remotely) -- but they
keep track of each user who uses a 'remote desktop', and accesses
a program like WORD, to make sure you only can use the number of
"remote sessions" you paid for.

If you want a multi-user computer, you need to run linux or
something else.  But both apple and MS have gone with the
1-user-1-licence model.

The recent push to convert linux to use systemd -- is all about
reducing the functionality of linux to require the same thing -- so 
1 system monitor (systemd) can keep track of how many users are

using "licensed seats" --- so vendors can force you to pay 10-100
times for the same program.  It's also about locking down linux so
that you can't easily your own programs to get around such licensing
mechanisms (you'd have to "jailbreak" your computer -- as is done
with smartphones these days, to allow you to run what you want on
your own computer).

If you want the remote display thing, use 'X' while it is still
available and not replaced by some encrypted-proprietary (but open
source) replacement that restrict what you can do on your computer
(effectively reducing it to a "console" -- as in gaming console that
only runs the programs that the manufacturer permits).




--
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: cygport: 'announce' feature branch

[Ken Brown]

On 11/3/2015 3:06 AM, Yaakov Selkowitz wrote:

I just created a new 'announce' feature branch in cygport git:

https://github.com/cygwinports/cygport/tree/announce

The new 'announce' command generates an announcement template from
the .cygport file based on NAME/VERSION/RELEASE, PKG_NAMES, and
DESCRIPTION, to which you can easily add release-specific information,
and then sends the message via an SMTP server.  Note that this adds


This is a nice feature.  Thanks.


dependencies on perl-Authen-SASL, perl-MIME-tools, and


perl-MIME-tools isn't in the distro yet.  Achim?


perl-Net-SMTP-SSL, and requires several new SMTP_* configuration options
in cygport.conf.

Feedback and patches welcome.


If there's no mailserver configured, I'd like to see cygport save the 
mbox file in the current directory and give an informational message, 
rather than saving it in /tmp and giving an error message.  Users might 
want to simply paste it into an email, and the error message seems a 
little unfriendly.


Ken

P.S. You still haven't applied the texlive patch from 
https://cygwin.com/ml/cygwin-apps/2015-08/msg00019.html; is this just an 
oversight, or do you need me to explain in more detail why it's needed?

Re: cygport: 'announce' feature branch

[Yaakov Selkowitz]

On Tue, 2015-11-03 at 18:23 -0500, Ken Brown wrote:
> On 11/3/2015 3:06 AM, Yaakov Selkowitz wrote:
> > I just created a new 'announce' feature branch in cygport git:
> >
> > https://github.com/cygwinports/cygport/tree/announce
> >
> > The new 'announce' command generates an announcement template from
> > the .cygport file based on NAME/VERSION/RELEASE, PKG_NAMES, and
> > DESCRIPTION, to which you can easily add release-specific information,
> > and then sends the message via an SMTP server.  Note that this adds
> 
> This is a nice feature.  Thanks.
> 
> > dependencies on perl-Authen-SASL, perl-MIME-tools, and
> 
> perl-MIME-tools isn't in the distro yet.

Good point, I just moved it in from Ports.

> If there's no mailserver configured, I'd like to see cygport save the 
> mbox file in the current directory and give an informational message, 
> rather than saving it in /tmp and giving an error message.  Users might 
> want to simply paste it into an email, and the error message seems a 
> little unfriendly.

First, I have already changed SMTP_SERVER to default to localhost,
matching git's behaviour.  (If it wasn't already painfully obvious, this
is all modelled after git send-email.)  Therefore, the error message now
reflects an actual failure to send the message.  As for the location of
the mbox file, it's something I'm willing to consider.

> P.S. You still haven't applied the texlive patch from 
> https://cygwin.com/ml/cygwin-apps/2015-08/msg00019.html; is this just an 
> oversight, or do you need me to explain in more detail why it's needed?

Oversight; August was a busy month.  Applied.

--
Yaakov

Re: Unison 2.43.3 fails to synchronize execute permission bit

[Ms. Alex Hankins]

On Nov 3, 2015 9:43 AM, "Andrew Schulman schulman.andrew-at-epa.gov
|cygwin|"  wrote:
>
> > There was a bug with the umask in the test script.  I have fixed it
> > and attached it.
>
> Thanks for reporting this.  I haven't had time to look at it yet, but I
> will when I can.  My guess is that the only thing I'll be able to do is
> report it upstream, to the unison-users list.  Feel free to do the same if
> I don't get to it first.  They've been pretty responsive over the years in
> supporting Cygwin.
>
> Have you checked to see whether the same problem happens with earlier
> versions of Unison?  That would help.

Thank you very much for replying, Andrew. I just reproduced it in
these versions (from `unison -version`):

2.27.157
2.32.52
2.40.102
2.45.28
2.48.3

I will try to post here if I get around to reporting it to the unison list.

--
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: Error accessing mapped drive >2TB?

[Warren Young]

On Oct 26, 2015, at 5:15 AM, Corinna Vinschen wrote:
> 
> On Oct 23 16:15, Warren Young wrote:
>> On Oct 23, 2015, at 8:30 AM, Jeffrey Altman wrote:
>>> While Apple's design choices do not fit with the expectations of Cygwin
>>> they are not necessarily wrong.
>> 
>> So, should I send Apple this code, or not?
>> 
>>  http://pastebin.com/uZdDZPgi
> 
> Wouldn't hurt I guess.  They are free to ignore us, of course :}

I finally got around to writing this up.  It’s radar ID 23381990 at 
https://bugreport.apple.com/

You might want to read it over.  I’m not certain I’m describing the problem 
clearly or completely.
--
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

bump libusb packages?

[KIMURA Masaru]

Hi,

can someone bump libusb packages to v1.0.20 or HEAD?
FYI, v1.0.20 and HEAD have a compilation issue[1],
was already reported to the upstream, but is not fixed ATM.

Peace,
-
[1] https://github.com/libusb/libusb/issues/104
-
$ cygcheck -c -d libusb1.0 libusb1.0-devel
Cygwin Package Information
Package  Version
libusb1.01.0.19-1
libusb1.0-devel  1.0.19-1

$ cd ~/git-repos
$ git clone https://github.com/libusb/libusb.git
$ cd libusb
$ git log v1.0.19... | grep -e 'Windows:'
Windows: Fix potential memory leak
Windows: Regenerate libusb-1.0.def file from latest DLL
Windows: Fix some build warnings/link issues
Windows: Close HID handles when closing composite devices
Windows: Remove redundant check in windows_claim_interface()
Windows: Destroy autoclaim_lock during cleanup
Windows: Check for "calloc" allocation failure.
Windows: Remove erroneous call to CloseHandle and add comments
Windows: Improve monotonic clock_gettime() implementation
Windows: Fix wIndex in setup packet for config descriptor request
Windows: Fix broken build caused by missing rename in 63a440f1
Windows: Free all WinUSB handles when closing a device
Windows: Direct control requests to a specific interface when possible
Windows: fix 2 bugs in windows_handle_events()
Windows: Silence VS2013 code analysis warnings
Windows: Fix cygwin64 build
Windows: Define WINVER to fix building on MinGW

--
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: fstat st_size on open files on Parallels filesystem is wrong

[Jonathan Lennox]

On Tuesday, November 3 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
saying:

> Btw., there's more than one problem here.  The fact that all drives
> have the same volume name *and* a serial number of 0 leads to all
> drives being identified as the same drive.  I have to add some code
> creating a reproducible serial number from scratch if the original
> serial number is 0, but for testing, I didn't implement this yet.

I've confirmed that this is the case for all the prlsf drives I have (drives
U:-Z:).

> Talking about testing.  I created a test DLL which provides a lot
> of output when stracing the calls.  I'll send you a private mail
> with the URL to this DLL in a minute.  Please install it, and under
> that DLL, run
> 
>   $ strace -o stat.trace ./stat-size-test.exe /cygdrive/y/foo
> 
> I'll need to have a look into that strace to (hopefully) see what's
> going wrong.

Attached.

--- Process 3620 created
--- Process 3620 loaded C:\Windows\System32\ntdll.dll at 7FFA60F2
--- Process 3620 loaded C:\Windows\System32\kernel32.dll at 7FFA60CC
--- Process 3620 loaded C:\Windows\System32\KernelBase.dll at 7FFA5E41
--- Process 3620 thread 6728 created
--- Process 3620 loaded C:\cygwin64\bin\cygwin1.dll at 00018004
--- Process 3620 thread 3204 created
8   8 [main] stat-size-test (3620) 
**
  407 415 [main] stat-size-test (3620) Program name: 
Y:\Emacs-Modtime\stat-size-test.exe (windows pid 3620)
  285 700 [main] stat-size-test (3620) OS version:   Windows NT-10.0
  295 995 [main] stat-size-test (3620) 
**
  3471342 [main] stat-size-test (3620) sigprocmask: 0 = sigprocmask (0, 
0x0, 0x180301128)
  5881930 [main] stat-size-test 3620 open_shared: name shared.5, n 5, 
shared 0x18003 (wanted 0x18003), h 0xAC, *m 6
  2872217 [main] stat-size-test 3620 user_heap_info::init: heap base 
0x6, heap top 0x6, heap size 0x2000 (536870912)
  2922509 [main] stat-size-test 3620 open_shared: name 
S-1-5-21-4096061939-177889333-3710151321-1394.1, n 1, shared 0x18002 
(wanted 0x18002), h 0xA8, *m 6
  2672776 [main] stat-size-test 3620 user_info::create: opening user shared 
for 'S-1-5-21-4096061939-177889333-3710151321-1394' at 0x18002
  3083084 [main] stat-size-test 3620 user_info::create: user shared version 
AB1FCCE8
  2933377 [main] stat-size-test 3620 fhandler_pipe::create: name 
\\.\pipe\cygwin-e022582115c10879-3620-sigwait, size 11440, mode 
PIPE_TYPE_MESSAGE
  3093686 [main] stat-size-test 3620 fhandler_pipe::create: pipe read 
handle 0xC4
  2683954 [main] stat-size-test 3620 fhandler_pipe::create: CreateFile: 
name \\.\pipe\cygwin-e022582115c10879-3620-sigwait
  2994253 [main] stat-size-test 3620 fhandler_pipe::create: pipe write 
handle 0xC8
  2824535 [main] stat-size-test 3620 dll_crt0_0: finished dll_crt0_0 
initialization
--- Process 3620 thread 444 created
 10515586 [sig] stat-size-test 3620 wait_sig: entering ReadFile loop, 
my_readsig 0xC4, my_sendsig 0xC8
  3385924 [main] stat-size-test 3620 time: 1446618094 = time(0x0)
  5576481 [main] stat-size-test 3620 mount_info::conv_to_posix_path: 
conv_to_posix_path (Y:\Emacs-Modtime, no-keep-rel, no-add-slash)
  3116792 [main] stat-size-test 3620 normalize_win32_path: Y:\Emacs-Modtime 
= normalize_win32_path (Y:\Emacs-Modtime)
  2277019 [main] stat-size-test 3620 mount_info::conv_to_posix_path: 
/cygdrive/y/Emacs-Modtime = conv_to_posix_path (Y:\Emacs-Modtime)
  2987317 [main] stat-size-test 3620 sigprocmask: 0 = sigprocmask (0, 0x0, 
0x600018128)
  5307847 [main] stat-size-test 3620 _cygwin_istext_for_stdio: fd 0: not 
open
  2358082 [main] stat-size-test 3620 _cygwin_istext_for_stdio: fd 1: not 
open
  2178299 [main] stat-size-test 3620 _cygwin_istext_for_stdio: fd 2: not 
open
  3828681 [main] stat-size-test (3620) open_shared: name cygpid.3620, n 
3620, shared 0x18001 (wanted 0x18001), h 0xF0, *m 2
  2328913 [main] stat-size-test (3620) time: 1446618094 = time(0x0)
  2279140 [main] stat-size-test 3620 pinfo::thisproc: myself dwProcessId 
3620
  3769516 [main] stat-size-test 3620 environ_init: GetEnvironmentStrings 
returned 0x3ADB00
  2749790 [main] stat-size-test 3620 environ_init: 0x6000284F0: !::=::\
  296   10086 [main] stat-size-test 3620 environ_init: 0x600028510: 
ALLUSERSPROFILE=C:\ProgramData
  306   10392 [main] stat-size-test 3620 environ_init: 0x600028540: 
APPDATA=C:\Users\jonathan.VIDYOCRM\AppData\Roaming
  299   10691 [main] stat-size-test 3620 environ_init: 0x600028580: 
COMMONPROGRAMFILES=C:\Program Files\Common Files
  297   10988 [main] stat-size-test 3620 environ_init: 0x6000285C0: 
COMPUTERNAME=VIDYO-LT0519-10
  278   11266 [main] stat-size-test 3620 environ_init: 0x6000285F0: 
COMSPEC=C:\Windows\system32\cmd.exe
  275   11541 [main] stat-size-test 3620 

Re: Unison 2.43.3 fails to synchronize execute permission bit

[Andrew Schulman]

> There was a bug with the umask in the test script.  I have fixed it
> and attached it.

Thanks for reporting this.  I haven't had time to look at it yet, but I
will when I can.  My guess is that the only thing I'll be able to do is
report it upstream, to the unison-users list.  Feel free to do the same if
I don't get to it first.  They've been pretty responsive over the years in
supporting Cygwin.

Have you checked to see whether the same problem happens with earlier
versions of Unison?  That would help.
 
> On Thu, Oct 29, 2015 at 11:26 AM, L <***> wrote:
> > On Wed, Oct 28, 2015 at 2:55 PM,   wrote:
> >> When synchronizing two directories on the same NTFS-formatted drive, 
> >> unison (with -perms 0o1777) fails to set execute permissions on new files. 
> >>  (It also fails to detect changes in execute permissions and to set them 
> >> on existing files.)
> >>...
> >
> > I forgot cygcheck.out.  I have attached it.
> >
> > Ms. Alex Hankins


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