Online Reviews Service for Cygwin

[Seema]

Hi,

If you want to popular your Business in International or Local area.
Therefore, you need our online reputation services. So people can trust
your company by your Online Reviews.

Now this days every company looking for good reviews on their wall, SO why
not you!!!

*We Offer Services (Hotel, Restaurants, Café, Clinic, Shop, Products and
Services**):*

·  Google Review

·  Tripadvisor Reviews

·  Amazon Review

·  Ecommerce Products Review

·  Ecommerce Products Upload

·  Facebook Review

·  Instagram Review

We have already done working for over 50+ Company, also we are currently
working for 12 live projects.

If you are Interested, Please Email us back for full proposal and pricing.

We are waiting for good
response.

24*7 Online Email, Skype and WhatsApp Support.

*Thanks & Regards,*
Natalie Johnson
Business Development Manager
Note: Simply write NO for unsubscribe. We'll never contact you again.

--
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: sshd permits logon using disabled user?

[Corinna Vinschen]

On Jan 28 14:49, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart  wrote:
> 
> > Thank you. I wanted to point out that I have not had a chance to test
> > using a non-domain computer yet. I will try that scenario as well.
> 
> Hi Corinna,
> 
> I unjoined a Windows 7 machine from the domain and tested as follows:
> 
> 1. Ran setup and installed cygwin
> 
> 2. Ran sshd-host-config and answered "no" to install as service
> 
> 3. Installed service using this command line:
> 
> cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> "-D" -y "tcpip"
> 
> 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> latest snapshot
> 
> When I try to start the service, I get error 1067 ("the process
> terminated unexpectedly"). Event log states:
> 
> cygsshd: PID : starting service `cygsshd' failed: fork: 11,
> Resource temporarily available
> 
> If I start bash elevated and run this:
> 
> /usr/sbin/sshd -d
> 
> It starts and listens on port 22 and I can connect.
> 
> Thoughts?

I can reproduce this on W7, while it works fine on W10.  Unfortunately I
haven't much time today and tomorrow but I'll try to get around to it
Thursday or Friday.

In the meantime, can you try the snapshots which one started to
introduce this issue?


Thanks and sorry for the hassle,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

On Jan 29 12:56, Corinna Vinschen wrote:
> On Jan 28 14:49, Bill Stewart wrote:
> > On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart  wrote:
> > 
> > > Thank you. I wanted to point out that I have not had a chance to test
> > > using a non-domain computer yet. I will try that scenario as well.
> > 
> > Hi Corinna,
> > 
> > I unjoined a Windows 7 machine from the domain and tested as follows:
> > 
> > 1. Ran setup and installed cygwin
> > 
> > 2. Ran sshd-host-config and answered "no" to install as service
> > 
> > 3. Installed service using this command line:
> > 
> > cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> > "-D" -y "tcpip"
> > 
> > 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> > latest snapshot
> > 
> > When I try to start the service, I get error 1067 ("the process
> > terminated unexpectedly"). Event log states:
> > 
> > cygsshd: PID : starting service `cygsshd' failed: fork: 11,
> > Resource temporarily available
> > 
> > If I start bash elevated and run this:
> > 
> > /usr/sbin/sshd -d
> > 
> > It starts and listens on port 22 and I can connect.
> > 
> > Thoughts?
> 
> I can reproduce this on W7, while it works fine on W10.  Unfortunately I
> haven't much time today and tomorrow but I'll try to get around to it
> Thursday or Friday.
> 
> In the meantime, can you try the snapshots which one started to
> introduce this issue?

Never mind, I found the culprit.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

On Jan 29 13:12, Corinna Vinschen wrote:
> On Jan 29 12:56, Corinna Vinschen wrote:
> > On Jan 28 14:49, Bill Stewart wrote:
> > > On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart  wrote:
> > > 
> > > > Thank you. I wanted to point out that I have not had a chance to test
> > > > using a non-domain computer yet. I will try that scenario as well.
> > > 
> > > Hi Corinna,
> > > 
> > > I unjoined a Windows 7 machine from the domain and tested as follows:
> > > 
> > > 1. Ran setup and installed cygwin
> > > 
> > > 2. Ran sshd-host-config and answered "no" to install as service
> > > 
> > > 3. Installed service using this command line:
> > > 
> > > cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> > > "-D" -y "tcpip"
> > > 
> > > 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> > > latest snapshot
> > > 
> > > When I try to start the service, I get error 1067 ("the process
> > > terminated unexpectedly"). Event log states:
> > > 
> > > cygsshd: PID : starting service `cygsshd' failed: fork: 11,
> > > Resource temporarily available
> > > 
> > > If I start bash elevated and run this:
> > > 
> > > /usr/sbin/sshd -d
> > > 
> > > It starts and listens on port 22 and I can connect.
> > > 
> > > Thoughts?
> > 
> > I can reproduce this on W7, while it works fine on W10.  Unfortunately I
> > haven't much time today and tomorrow but I'll try to get around to it
> > Thursday or Friday.
> > 
> > In the meantime, can you try the snapshots which one started to
> > introduce this issue?
> 
> Never mind, I found the culprit.

Please try the snapshots I just uploaded to https://cygwin.com/snapshots/
They should fix the problem.  It turned out that I restricted the
permissions of processes too much for Windows 7.  The same code works
fine since Windows 8.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Unable to remap dll to same address as parent

[Maxim Kupfer]

I have a peculiar problem, where my python web application built using
flask no longer works when running in debug mode. I keep getting an error
that it is unable to remap _lbfgsb.cpython-36m-x86_64-cygwin.dll.

I've already tried rebasing in every shape and form, even tried this one (Re:
rebaseall rebasing dlls into cygwin address range?
) as a last ditch effort,
but no luck. Any other suggestions?

Thanks,
Maxim

--
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: sshd permits logon using disabled user?

[Bill Stewart]

On Tue, Jan 29, 2019 at 10:05 AM Corinna Vinschen
 wrote:

> Please try the snapshots I just uploaded to https://cygwin.com/snapshots/
> They should fix the problem.  It turned out that I restricted the
> permissions of processes too much for Windows 7.  The same code works
> fine since Windows 8.

Tested updated DLL - working on Windows 7. Excellent - thank you!

Bill

--
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: sshd permits logon using disabled user?

[Corinna Vinschen]

On Jan 29 11:18, Bill Stewart wrote:
> On Tue, Jan 29, 2019 at 10:05 AM Corinna Vinschen
>  wrote:
> 
> > Please try the snapshots I just uploaded to https://cygwin.com/snapshots/
> > They should fix the problem.  It turned out that I restricted the
> > permissions of processes too much for Windows 7.  The same code works
> > fine since Windows 8.
> 
> Tested updated DLL - working on Windows 7. Excellent - thank you!
> 
> Bill

Thanks a lot for testing,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Unable to remap dll to same address as parent

[Marco Atzeri]

Am 29.01.2019 um 19:02 schrieb Maxim Kupfer:

I have a peculiar problem, where my python web application built using
flask no longer works when running in debug mode. I keep getting an error
that it is unable to remap _lbfgsb.cpython-36m-x86_64-cygwin.dll.

I've already tried rebasing in every shape and form, even tried this one (Re:
rebaseall rebasing dlls into cygwin address range?
) as a last ditch effort,
but no luck. Any other suggestions?

Thanks,
Maxim



how you are rebasing _lbfgsb.cpython-36m-x86_64-cygwin.dll ?

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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] TEST: Cygwin 3.0.0-0.1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 3.0.0-0.1

This release comes with a couple of new features and some interesting
bug fixes.

It also changes the output of uname(2) for newly built applications.
Applications built so far (that includes uname(1) from coreutils)
will still print the old uname output.  The new format allows for longer
strings.  Compare:

Old uname content:

  sysname:  CYGWIN_NT-10.0 or  CYGWIN_NT-10.0-WOW   on WOW64
  release:  3.0.0(0.335/5/3)   or  3.0.0s(0.335/5/3)for snapshots
  version:  2019-01-29 19:23   Local build time 

Upcoming new uname content:

  sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
  release:  3.0.0-335.x86_64   or  3.0.0-335.x86_64.snap
  version:  2019-01-29 19:23 UTC   Build time in UTC


Please test.

===

What's new:
---

- Support for CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE,
  CLOCK_MONOTONIC_RAW, CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM,
  CLOCK_BOOTTIME_ALARM clocks.

- Support for case sensitive directories.  mkdir(2) automatically
  creates directories within the Cygwin installation dir as case
  sensitive now.

  This feature requires Windows 10 1803 or later and WSL installed!

- New file ioctls's FS_IOC_GETFLAGS and FS_IOC_SETFLAGS.  The actual
  inode flags are Cygwin-specific.  This allows to set or reset
  DOS attributes, file sparseness, FS level encryption and compression,
  as well as directory case sensitivity programatically.

- New tools chattr(1) and lsattr(1) to utilize setting and viewing the
  aforementioned new ioctl's on the command line.

- Support for exFAT.

- Support Linux-specific open(2) flag O_PATH.

- Support Linux-specific linkat(2) flag AT_EMPTY_PATH.

- Support overrun counter for posix timers (via timer_getoverrun() or
  siginfo_t::si_overrun).

- New APIs: signalfd, timerfd_create, timerfd_gettime, timerfd_settime,
  timer_getoverrun.


What changed:
-

- clock_nanosleep, pthread_condattr_setclock and timer_create now support
  all clocks, except CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID.

- clock_setres is a no-op now.

- Use the new POSIX unlink semantics on NTFS starting with Windows 10 1709.
  Deleting an in-use file now actually removes the file, rather than moving
  it to the recycler bin.

- Use the new POSIX rename semantics on NTFS starting with Windows 10 1809.
  Renaming a file to another in-use file now actually removes the other file,
  rather than moving it to the recycler bin.

- open(..., O_TMPFILE) now moves the file to the trash bin immediately,
  to free the parent directory.

- Wctype functions updated to Unicode 11.0.

- Remove matherr, and SVID and X/Open math library configurations.
  Default math library configuration is now IEEE.

- Improve uname(2) for newly built applications.

- Kerberos/MSV1_0 S4U authentication replaces two old methods:
  Creating a token from scratch and Cygwin LSA authentication package.


Bug Fixes
-

- Fix a thread race when initializing CLOCK_MONOTONIC.
  Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00017.html

- Fix early timeout from pthread_cond_timedwait.
  Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00171.html

- Fix a bug in recognizing remote FAT/FAT32/exFAT correctly.

- Allow open(2)/stat(2)/linkat(2) of a file via /proc/PID/fd/DESCRIPTOR
  even if file has been deleted.
  Addresses: https://cygwin.com/ml/cygwin/2018-12/msg00125.html
 https://cygwin.com/ml/cygwin/2018-12/msg00028.html

- Fix a bug in select(2) when polling HANDLE-less descriptors.

- Fix WEOF handling in wctype functions.
  Addresses: https://cygwin.com/ml/cygwin/2018-12/msg00173.html

- Fix thread names in GDB when cygthreads get reused.

- Fix return value of gethostname in a border case.

- Disallow seteuid on disabled or locked out accounts.
  Addresses: https://cygwin.com/ml/cygwin/2019-01/msg00197.html

===


Have fun,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Recent snapshots somewhat fail under W7

[Denis Excoffier]

Hello,

I tried the (numerous) recent snapshots with W10 (1709) with no problem (except 
for the isolated 20190115 snapshot and also that « cp cygwin0.dll 
/usr/bin/cygwin1.dll » now fails but this is another story). The recent 
snapshots with W7 fail somewhat (but the system seems to function more or 
less), i've got the following message with W7:

  0 [main] tcsh 15528 fixup_mmaps_after_fork: VirtualQueryEx failed for 
MAP_PRIVATE address 0x6FA, Win32 error 5
368 [main] tcsh 15528 
D:\Users\dexcoff1\dexcoff1\cyglcl\uxl\tcsh-6.20.00\bin\tcsh.exe: *** fatal 
error in forked process - recreate_mmaps_after_fork_failed
700 [main] tcsh 15528 cygwin_exception::open_stackdumpfile: Dumping stack 
trace to tcsh.exe.stackdump
  0 [main] tcsh 19080 fork: child -1 - forked process 15528 died 
unexpectedly, retry 0, exit code 0x100, errno 11
No more processes.

I had a look into sigproc.cc  and noticed that recently 
(commit 69cc7a068656b5c6ef07ca079a213f801e02e650, dated 2019-01-27, 
DUPLICATE_SAME_ACCESS has been replaced by 0 in a call to DuplicateHandle(). I 
switched it back, re-compiled and the fork problem above disappeared. Don’t 
know the impact on W10.

HTH.

Denis Excoffier.





--
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: Incorrect signal behavior in multi-threaded processes

[Dan Bonachea]

> A minimal test program is copied below and also available here:
> https://upc-bugs.lbl.gov/bugzilla/attachment.cgi?id=589

> It's worth noting POSIX 1003.1-2016 sec XRAT.B.2.4.1 (p.3577)
> specifically requires that any given signal should be delivered to
> exactly one thread. Also the spec for abort (p.565) requires the
> signal to be delivered as if by `raise(SIGABRT)` (p.1765) aka.
> `pthread_kill(pthread_self(),SIGABRT)` (p.1657), which implies
> any registered SIGABRT handler should run only on the thread
> which called abort().

Poking around further, I find that replacing the signal generation
code in the test program for all cases with :

  pthread_kill(pthread_self(),sigid)

generates compliant signal delivery behavior!

This reveals that Cygwin is theoretically capable of correctly
delivering signals to a selected "non-primordial" thread; but the
various forms of signal generation exercised in the original test are
apparently not leading to correct use of that internal mechanism.

To review, the POSIX 1003.1-2017 specification for abort() says:

   The SIGABRT signal shall be sent to the calling process as if by means
   of raise() with the argument SIGABRT.

and the specification for raise() says:

The effect of the raise() function shall be equivalent to calling:
pthread_kill(pthread_self(), sig);

but this appears to NOT currently be the case in Cygwin.
The current implementation of raise() in winsup/cygwin/signal.cc:

 300 extern "C" int
 301 raise (int sig)
 302 {
 303   return kill (myself->pid, sig);
 304 }

I believe this is the root cause of the observed misbehaviors with
both raise() and abort(). The Cygwin implementation of raise(sig) is
incorrectly generating a process-scope signal (discarding thread
information) rather than sending the signal to the *calling* thread,
as required by POSIX, via the same mechanism as
pthread_kill(pthread_self(),sig).

If the implementation of raise() in libc was internally replaced with
pthread_kill(pthread_self(), sig), I believe that should resolve two
of the three failure modes we've seen. I have no idea what negative
consequences (if any) there may be to that proposed change.

It's worth noting that an end user could potentially deploy a
(fragile) partial workaround by macro-defining abort and raise to
pthread_kill; but that notably would fail to capture calls made from
within libc (such as the abort() call made from
cygwin/assert.cc:__assert_func() when an invocation of assert() from
 fails).

The remaining failure mode is a SIGSEGV generated from a programming
error (e.g. null pointer dereference) on a non-primordial thread. This
should ideally be fixed to deliver a pthread_kill() to the offending
thread, instead of the current process-wide abnormal termination that
ignores signal handlers. I agree with Madison that there is probably
no user-level workaround to cover this case at all, and I don't know
what may be required in the Win API to make this happen correctly.

Thoughts?
-D

--
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: Cygwin 3.0.0-0.1

[Steven Penny]

On Tue, 29 Jan 2019 20:59:59, Corinna Vinschen wrote:

- New file ioctls's FS_IOC_GETFLAGS and FS_IOC_SETFLAGS.  The actual
  inode flags are Cygwin-specific.  This allows to set or reset
  DOS attributes, file sparseness, FS level encryption and compression,
  as well as directory case sensitivity programatically.

- New tools chattr(1) and lsattr(1) to utilize setting and viewing the
  aforementioned new ioctl's on the command line.


these are very much appreciated. going back to my previous post:

https://cygwin.com/ml/cygwin/2018-12/msg00163.html

i re-ran with the new tool, however i am getting unexpected result:

$ lsattr /cygdrive/c
-hs- /cygdrive/c/$Recycle.Bin
-hs- /cygdrive/c/Config.Msi
 /cygdrive/c/cygwin64
lsattr: Device or resource busy while trying to open /cygdrive/c/pagefile.sys
 /cygdrive/c/PerfLogs
r--- /cygdrive/c/Program Files
r--- /cygdrive/c/Program Files (x86)
-h---n-- /cygdrive/c/ProgramData
-hs--n-- /cygdrive/c/Recovery
-hs- /cygdrive/c/System Volume Information
r--- /cygdrive/c/Users
 /cygdrive/c/Windows

compare with cmd.exe:


dir /A C:\

2018-10-08  11:20 AM  $Recycle.Bin
2019-01-10  05:20 PM  Config.Msi
2019-01-29  06:33 PM  cygwin64
2009-07-13  11:08 PM Documents and Settings [C:\Users]
2018-10-08  07:48 PM  NVIDIA
2018-12-23  09:57 AM17,138,294,784 pagefile.sys
2009-07-13  09:20 PM  PerfLogs
2019-01-01  02:10 PM  Program Files
2018-12-19  01:19 PM  Program Files (x86)
2018-10-31  06:07 PM  ProgramData
2018-10-08  11:14 AM  Recovery
2019-01-29  03:36 PM  System Volume Information
2018-11-18  01:10 AM  Users
2018-11-09  08:18 AM  Windows

or attrib:


attrib C:\pagefile.sys

A  SHC:\pagefile.sys


--
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: Cygwin 3.0.0-0.1

[Steven Penny]

On Tue, 29 Jan 2019 20:59:59, Corinna Vinschen wrote:

Hi folks,


I uploaded a new Cygwin test release 3.0.0-0.1

This release comes with a couple of new features and some interesting
bug fixes.


something big broke here. as someone else reported here:

https://cygwin.com/ml/cygwin/2019-01/msg00276.html

i am getting similar result:

$ git log -1
  0 [main] git 4128 fixup_mmaps_after_fork: VirtualQueryEx failed for
MAP_PRIVATE address 0x6E1, Win32 error 5
828 [main] git 4128 C:\cygwin64\bin\git.exe: *** fatal error in forked process
- recreate_mmaps_after_fork_failed
1632 [main] git 4128 cygwin_exception::open_stackdumpfile: Dumping stack trace
to git.exe.stackdump
  0 [main] git 2632 fork: child -1 - forked process 4128 died unexpectedly,
retry 0, exit code 0x100, errno 11
error: cannot fork() for less: Resource temporarily unavailable

workaround is to stop forking:

$ git --no-pager log -1

Personally I am going back Cygwin 2 until this is resolved. Cheers


--
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: Weird mismatch between cdefs and stdatomic

[LRN]

On 28.01.2019 17:02, LRN wrote:
> This[0] and this[1]. One header checks for atomic C/CXX extensions *and* for
> the presence of a C++ compiler, while the other only checks for extensions.
> 
> The result is that the _Atomic() macro is *not* defined in cdefs.h when
> compiled with C++, but the stdatomic.h atomic macros assume that it is, and 
> try
> to access the "__val" struct member, with predictable and sad results.
> 
> I just stumbled upon this while compiling OpenSSL, and wanted to see if anyone
> else encountered this problem.
> 

There is also a "!defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L"
condition in cdefs.h that is not reproduced in stdatomic.h. So my initial guess
seems to have been incorrect - it's not about C vs C++ compiler, it's about C11
vs C99 compiler modes.



signature.asc
Description: OpenPGP digital signature