Re: Cygwin alongside WSL

[Brian Inglis]

On 2017-11-02 16:38, Thomas Wolff wrote:
> Am 02.11.2017 um 04:19 schrieb Brian Inglis:
>> On 2017-10-31 12:11, Thomas Wolff wrote:
>>> Am 27.10.2017 um 00:10 schrieb Thomas Wolff:
 Am 26.10.2017 um 18:13 schrieb Brian Inglis:
> On 2017-10-25 15:18, Thomas Wolff wrote:
>> Am 25.10.2017 um 20:30 schrieb Brian Inglis:
>>> On 2017-10-25 11:27, Brian Inglis wrote:
 On 2017-10-25 00:29, Thomas Wolff wrote:
> Am 25.10.2017 um 00:19 schrieb Angelo Graziosi:
>> Thomas Wolff wrote:
>>> Mintty 2.8.0 simplifies WSL integration a lot.
>>> In Cygwin, you can simply start e.g. mintty --WSL=Ubuntu (add
>>> -~ to start in
>>> the WSL home).
>> Does it mean that 2.8.0 does not need wslbridge [*] any more?
> No, sorry, I forgot to mention that wslbridge would have to be
> installed
> in /bin to make this work.
 As it is not a Cygwin package, I have installed wslbridge in
 /usr/local/bin/,
 which is in the system Path in Windows format, so also in the
 Cygwin path in
 Unix format - will this work?
>>> Would a symlink, winsymlink, or .lnk as /bin/wslbridge to
>>> /usr/local/bin/?
>> Why don't you just try it? Both wslbridge and wslbridge-backend must
>> reside in
>> /bin, hard links will work of course.
> It looks like without the Fall Update --WSL= does not work with either
> no/default distribution found, and the same result with a variety of
> obvious names:
>
> ...
>
> It would be nice if --WSL did the right thing for legacy installs also.
 Yes, I am aware of this gap, see
 https://github.com/mintty/wsltty/issues/64
>>> This should be working now with mintty 2.8.1. Please try.
>> This is now working nicely with --WSL and symlinks from
>> /usr/local/bin/wslbridge* to /usr/bin/.
>> Using mintty makes cross-checking Cygwin vs Linux operation very pleasant.
>>
>> [Nitpick: with --WSL, argument "-" does not find DefaultUserName in
>> BasePath/rootfs/etc/passwd and launch the default shell as the login shell:
>> /bin/wslbridge: Exit 1.
>> error: could not exec '-': No such file or directory]
> Both features, finding the default user and starting a login shell, would 
> depend
> on improved wslbridge support.
> About "-", I've submitted an issue:
> https://github.com/rprichard/wslbridge/issues/18
> 
>> Thanks for all your efforts since you adopted this package, in updating it to
>> modern standards, all the Unicode, vtterm, and xterm support you have added, 
>> all
>> the new features and improvements in every release, adaptation for WSL, all 
>> the
>> fixes you constantly make, and your frequent releases.
> Thanks for flattering me :) Sounds good after all the people asking for ever
> more features, silly ones as well as good ones.

You and Ryan have done a stellar job of making Windows, Cygwin, and WSL more
useful for everyone who has come across your projects.

> Actually, after the WSL and Virtual Tabs endeavours, release frequency should
> become lower now.
> I'd still like to bundle the package with a number of themes and perhaps bell
> sounds, to populate the config directory not only with localization files. 
> I've
> so far hesitated because I don't want to get involved in copyright 
> discussions.
> Any idea or opinion?

Leverage the Unix GUI desktop projects with Cygwin compatible licenses.
There are a lot of themes, icon sets, sounds, and other resources available
which are not available in Cygwin, but are in other distros.

That's why I like WSL being easier to use with Cygwin: I can apt install or
apt-get build-dep and apt-get source --compile packages unavailable on Cygwin,
and use the resources or source, sharing directly between Cygwin, Ubuntu, and
Windows.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Cygwin alongside WSL

[Thomas Wolff]

Am 02.11.2017 um 04:19 schrieb Brian Inglis:

On 2017-10-31 12:11, Thomas Wolff wrote:

Am 27.10.2017 um 00:10 schrieb Thomas Wolff:

Am 26.10.2017 um 18:13 schrieb Brian Inglis:

On 2017-10-25 15:18, Thomas Wolff wrote:

Am 25.10.2017 um 20:30 schrieb Brian Inglis:

On 2017-10-25 11:27, Brian Inglis wrote:

On 2017-10-25 00:29, Thomas Wolff wrote:

Am 25.10.2017 um 00:19 schrieb Angelo Graziosi:

Thomas Wolff wrote:

Mintty 2.8.0 simplifies WSL integration a lot.
In Cygwin, you can simply start e.g. mintty --WSL=Ubuntu (add
-~ to start in
the WSL home).

Does it mean that 2.8.0 does not need wslbridge [*] any more?

No, sorry, I forgot to mention that wslbridge would have to be
installed
in /bin to make this work.

As it is not a Cygwin package, I have installed wslbridge in
/usr/local/bin/,
which is in the system Path in Windows format, so also in the
Cygwin path in
Unix format - will this work?

Would a symlink, winsymlink, or .lnk as /bin/wslbridge to
/usr/local/bin/?

Why don't you just try it? Both wslbridge and wslbridge-backend must
reside in
/bin, hard links will work of course.

It looks like without the Fall Update --WSL= does not work with either
no/default distribution found, and the same result with a variety of
obvious names:

...

It would be nice if --WSL did the right thing for legacy installs also.

Yes, I am aware of this gap, see
https://github.com/mintty/wsltty/issues/64

This should be working now with mintty 2.8.1. Please try.

This is now working nicely with --WSL and symlinks from
/usr/local/bin/wslbridge* to /usr/bin/.
Using mintty makes cross-checking Cygwin vs Linux operation very pleasant.

[Nitpick: with --WSL, argument "-" does not find DefaultUserName in
BasePath/rootfs/etc/passwd and launch the default shell as the login shell:
/bin/wslbridge: Exit 1.
error: could not exec '-': No such file or directory]
Both features, finding the default user and starting a login shell, 
would depend on improved wslbridge support.
About "-", I've submitted an issue: 
https://github.com/rprichard/wslbridge/issues/18



Thanks for all your efforts since you adopted this package, in updating it to
modern standards, all the Unicode, vtterm, and xterm support you have added, all
the new features and improvements in every release, adaptation for WSL, all the
fixes you constantly make, and your frequent releases.
Thanks for flattering me :) Sounds good after all the people asking for 
ever more features, silly ones as well as good ones.
Actually, after the WSL and Virtual Tabs endeavours, release frequency 
should become lower now.
I'd still like to bundle the package with a number of themes and perhaps 
bell sounds, to populate the config directory not only with localization 
files. I've so far hesitated because I don't want to get involved in 
copyright discussions. Any idea or opinion?

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

python2 now depends on python2-test... and pulls many graphical packages

[Jérôme Bouat]

Hello,

Today the update of the python2 package added a dependency to python2-test. 
Then python2-test depends on idle2 which pulls many Tk packages.

How can I keep python2 without python2-test ?

--
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: Can I change the windows icon from command line?

[Thomas Wolff]

Am 02.11.2017 um 14:38 schrieb cyg Simple:

On 11/2/2017 2:47 AM, Thomas Wolff wrote:

Thanks, Brian, for the links and the sample code which will make it easier.
This is about changing the icon, to get that sorted out.
I referred to changing the icon label (an existing sequence supported by
xterm), i.e. the text shown in the taskbar, which cannot be changed in
Windows as far as I know as it's always the same as the window title.

RXVT managed to change the title based on the xterm escape sequences.
I've used that idea for various server connections in the past with RXVT.
Rxvt does not support more than mintty. We are not talking about window 
frame labels (window title)
but the labels that appear next to the icons in the Windows taskbar, or 
(if configured away) popup up floating there.


--
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: Can I change the windows icon from command line?

[Thomas Wolff]

Hi Andrey,

Greetings, Thomas Wolff!


I referred to changing the icon label (an existing sequence supported by
xterm), i.e. the text shown in the taskbar, which cannot be changed in
Windows as far as I know as it's always the same as the window title.

Two thoughts on this:

1. The taskbar button title is not necessarily the same as [visible]
application window title.
One of the cleanest solutions is to create a frameless main window and embed
your actual application window inside it. Downside is that the visible
application window titlebar may not look right.
Another solution is to create two windows, one only shown in taskbar, one is
an actual app window, and repost all messages from taskbar to the application
window. Downside is that not all shell features may work properly, such as
minimize-restore on repeated clicks.
In support of this feature, I can say that I have restricted space for taskbar
labels myself (approx 10 symbols) and have to be creative with window titles
from various sources to clearly identify the windows.
That including dances with /etc/debian_chroot and manual PROMPT_COMMAND 
settings.
Yeah, I can imagine that some *very* tricky solution with hidden windows 
is possible,

but I'm sure at the price of lots of nerves and extensible testing.
I don't think it's worth the effort, especially as many people use icons 
only on the taskbar, not the labels.

But feel free to propose a patch :)


2. Since there's no direct solution for setting window icon, an existing
sequence could be reused for our purpose, since there's no clean way to make
it work straight. Or a new sequence could be invented.


--
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: [setup topic/libsolv] Crash after incomplete download

[Ken Brown]

On 11/2/2017 1:22 PM, Jon Turney wrote:

On 01/11/2017 20:38, Ken Brown wrote:
If there is a download failure and the user clicks Yes in response to 
"Download Incomplete.  Try again?", then setup will crash.  The crash 
occurs at PickView.cc:447 because i->source() is NULL.


Thanks for finding all these problems!

I haven't yet analyzed this in further detail, but the crux of the 
issue seems to be that we call do_ini_thread a second time without 
having cleaned out the package database and the libsolv pool.


This is probably a symptom of a more general problem, which is that we 
haven't thought carefully (or at least I haven't) about what happens 
when we visit certain pages for a second time, after the libsolv pool 
has been created.


The fact that this isn't considered at all at the moment makes me wonder 
if it's working correctly in this situation currently.  But, yeah, I 
agree that packagedb state should be cleared in this case.


I tried with the attached, but it still segfaults at the same place.

This seems to be because all the packagedb prep (including 
fixup_source_package_ids) is in OnInit() (which is only called once per 
page, but lazily), rather than OnActivate(), so probably some more 
restructuring is needed there :(


I guess we could move all that prep to OnActivate() but make sure it's 
only run when we've gotten to the chooser page from the site page (and 
not because the user pressed Back on the prereq page).  What about 
adding a 'prepped' data member to packagedb and using this to decide 
whether to run the prep code?


Before I work further on this, I have a UI question.  Is it really 
reasonable that we go back to the mirror selection page after 
"Download incomplete"?  I understand the rationale, which is that the 
user might want to try a different mirror after a download failure.  
But I personally have always found this annoying.  I would rather just 
retry the download, which is what the message ("Download Incomplete.  
Try again?") suggests is going to happen.


This makes perfect sense to me.

The path that an unattended install takes out of there is particularly 
convoluted, as well.


I suspect there's other terribleness in this area, like if you choose 
"No", the incomplete package download is left in the local package cache 
to fail it's checksum check on the next run...


+void
+packagedb::init ()
+{
+  installeddbread = 0;
+  installeddbver = 0;
+  packages.clear();
+  sourcePackages.clear();
+  categories.clear();
+  solver.clear();
+  basepkg = packageversion();
+  dependencyOrderedPackages.clear();


I think you also need solution.clear(), where the latter does 
essentially what SolverSolution::~SolverSolution() does.  (Or is it 
enough to just set solv = NULL?)  Otherwise, solv will be an invalid 
pointer when update is next called.


Ken

Re: Cygwin on Win10 much slower than Win7

[Vince Rice]

> On Nov 2, 2017, at 12:15 PM, Nellis, Kenneth  
> wrote:
> …
> I first noticed the problem with cygpath:
> On Win 7:
> 
> $ time cygpath abc
> abc
> 
> real0m0.016s
> user0m0.000s
> sys 0m0.015s
> $
> 
> On Win 10:
> 
> $ time cygpath abc
> abc
> 
> real0m0.105s
> user0m0.000s
> sys 0m0.062s

I have Win7x64 and Win10x64 VM's on the same physical Mac, both configured 
identically WRT disk, memory, etc. Both were just updated from setup, so are 
running same version of cygwin. Both were on newly started mintty's, and, in 
the case of Win7, just-started VM. (My Win10 VM has been up for a day or so.)

I ran cygpath 100 times in a loop (for i in {1..100} …), using the loop 
variable as the parameter to cygpath. I ran each loop three times, then 
averaged the times. Thus the times below are for 100 cygpaths.

On Win7, times were .790/.145/.396.
On Win10, times were 1.340/.350/.650.

Not enough for me to worry about, but it might be for you.
--
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: ftruncate64: add missing braces

[Corinna Vinschen]

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

commit ad15b8ccee7d4253e7f3a5dd69fe2ab8c67895b8
Author: Corinna Vinschen 
Date:   Thu Nov 2 19:13:09 2017 +0100

cygwin: ftruncate64: add missing braces

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 1807afc..a045dcd 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2967,12 +2967,14 @@ ftruncate64 (int fd, off_t length)
   int res = -1;
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
-res = cfd->ftruncate (length, true);
-if (res)
-  {
-set_errno (res);
-res = -1;
-  }
+{
+  res = cfd->ftruncate (length, true);
+  if (res)
+   {
+ set_errno (res);
+ res = -1;
+   }
+}
   else
 set_errno (EBADF);
   syscall_printf ("%R = ftruncate(%d, %D)", res, fd, length);

issue when download cpld

[Wenjie Wu]

Hi I got an warning message when perform some cpld download and it suggests me 
to contact you guys. Any ideas?
2 [main] od 1424 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  
Please report this problem to
the public mailing list cygwin@cygwin.com

  1 [main] od 2208 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] od 5564 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] od 5012 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] od 2452 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  2 [main] od 3588 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public



--
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: Proper way to run emacs from desktop

[David Karr]

On Thu, Nov 2, 2017 at 9:29 AM, Jon Turney  wrote:
> On 01/11/2017 21:57, David Karr wrote:
>>
>> On Wed, Nov 1, 2017 at 12:57 PM, Ken Brown  wrote:
>>>
>>> On 11/1/2017 1:08 PM, David Karr wrote:

 I install Cygwin every couple of years and then use it continuously
 without updates between those installations.  I installed it on a new
 laptop today, and I'm trying to work through issues.

 The current issue is running Emacs from the desktop.

 I had a shortcut working for a long time that does the following:
 -
 C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0
 /usr/local/bin/emacs.xml
 -
>
>
> Just '--display :0.0' is probably better, as it won't stop working when the
> Xserver is run without '-listen tcp'...

Sounds like a good idea, but I noticed that this change produces a
very odd side effect, and I've verified that going back makes it not
happen. I've tested going back and forth multiple times, with
repeatable results.

Normally, when I start emacs, the window appears in a particular
location, and with a particular height (and width, but I don't set
that).

I believe this is configured by the following lines in my .emacs file:
-
(set-frame-position (selected-frame) 0 0)
(set-frame-height (selected-frame) 60)
-

Setting the frame height to 60 results in a window that spans most of
the vertical space of my desktop.

Curiously, when I remove the "127.0.0.1" from the "display" option,
emacs starts up in the same location, but with about 2/3 of the
expected window height.  The window is easily expandable, but I'd
rather it be the height that I have configured initially.

Frankly, I find it hard to believe what I'm seeing, but I've gone back
and forth multiple times, and it's completely repeatable.  Could this
be caused by something odd in my X resources tree?

 The "run2" application doesn't appear to exist.  I checked my notes,
 and I can't tell whether I installed this from somewhere else the last
 time I did this.
>>>
>>>
>>> Just install the run2 package.  It's still available.
>>
>>
>> Ok.  I find the search facility in setup somewhat confusing.  I
>> couldn't find it before. I found it now, and I've installed it.
>
>
> You can also search using e.g.
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=run2.exe=x86_64
>

--
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: [setup topic/libsolv] Crash after incomplete download

[Jon Turney]

On 01/11/2017 20:38, Ken Brown wrote:
If there is a download failure and the user clicks Yes in response to 
"Download Incomplete.  Try again?", then setup will crash.  The crash 
occurs at PickView.cc:447 because i->source() is NULL.


Thanks for finding all these problems!

I haven't yet analyzed this in further detail, but the crux of the issue 
seems to be that we call do_ini_thread a second time without having 
cleaned out the package database and the libsolv pool.


This is probably a symptom of a more general problem, which is that we 
haven't thought carefully (or at least I haven't) about what happens 
when we visit certain pages for a second time, after the libsolv pool 
has been created.


The fact that this isn't considered at all at the moment makes me wonder 
if it's working correctly in this situation currently.  But, yeah, I 
agree that packagedb state should be cleared in this case.


I tried with the attached, but it still segfaults at the same place.

This seems to be because all the packagedb prep (including 
fixup_source_package_ids) is in OnInit() (which is only called once per 
page, but lazily), rather than OnActivate(), so probably some more 
restructuring is needed there :(


Before I work further on this, I have a UI question.  Is it really 
reasonable that we go back to the mirror selection page after "Download 
incomplete"?  I understand the rationale, which is that the user might 
want to try a different mirror after a download failure.  But I 
personally have always found this annoying.  I would rather just retry 
the download, which is what the message ("Download Incomplete.  Try 
again?") suggests is going to happen.


This makes perfect sense to me.

The path that an unattended install takes out of there is particularly 
convoluted, as well.


I suspect there's other terribleness in this area, like if you choose 
"No", the incomplete package download is left in the local package cache 
to fail it's checksum check on the next run...
From baec018e93c0e7cea7993c22a5e32f2065a1e7ae Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Thu, 2 Nov 2017 14:15:04 +
Subject: [PATCH setup] Empty packagedb and underlying solver pool if we go
 back to WM_APP_START_SETUP_INI_DOWNLOAD

XXX: this is probably still wrong as we can bypass this state?
---
 ini.cc|  3 +++
 libsolv.cc| 15 +++
 libsolv.h |  2 ++
 package_db.cc | 13 +
 package_db.h  |  1 +
 5 files changed, 34 insertions(+)

diff --git a/ini.cc b/ini.cc
index 0f8b927..e2ab08f 100644
--- a/ini.cc
+++ b/ini.cc
@@ -346,6 +346,9 @@ do_remote_ini (HWND owner)
 static bool
 do_ini_thread (HINSTANCE h, HWND owner)
 {
+  packagedb db;
+  db.init();
+
   size_t ini_count = 0;
   if (source == IDC_SOURCE_LOCALDIR)
 ini_count = do_local_ini (owner);
diff --git a/libsolv.cc b/libsolv.cc
index 9dd1eeb..7eecc29 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -316,6 +316,12 @@ void debug_callback(Pool *pool, void *data, int type, 
const char *str)
 }
 
 SolverPool::SolverPool()
+{
+  init();
+}
+
+void
+SolverPool::init()
 {
   /* create a pool */
   pool = pool_create();
@@ -333,6 +339,15 @@ SolverPool::SolverPool()
   pool_set_installed(pool, installed->repo);
 }
 
+void
+SolverPool::clear()
+{
+  repos.clear();
+  pool_free(pool);
+
+  init();
+}
+
 SolvRepo *
 SolverPool::getRepo(const std::string , bool test)
 {
diff --git a/libsolv.h b/libsolv.h
index 65e1610..366cd59 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -130,6 +130,7 @@ class SolverPool
 {
 public:
   SolverPool();
+  void clear();
   SolvRepo *getRepo(const std::string , bool test = false);
 
   // Utility class for passing arguments to addPackage()
@@ -158,6 +159,7 @@ public:
 
 
 private:
+  void init();
   Id makedeps(Repo *repo, PackageDepends *requires);
   Pool *pool;
 
diff --git a/package_db.cc b/package_db.cc
index 66e7f0a..5bf9009 100644
--- a/package_db.cc
+++ b/package_db.cc
@@ -47,6 +47,19 @@ packagedb::packagedb ()
 {
 }
 
+void
+packagedb::init ()
+{
+  installeddbread = 0;
+  installeddbver = 0;
+  packages.clear();
+  sourcePackages.clear();
+  categories.clear();
+  solver.clear();
+  basepkg = packageversion();
+  dependencyOrderedPackages.clear();
+}
+
 void
 packagedb::read ()
 {
diff --git a/package_db.h b/package_db.h
index d7127a6..a26c387 100644
--- a/package_db.h
+++ b/package_db.h
@@ -64,6 +64,7 @@ class packagedb
 {
 public:
   packagedb ();
+  void init();
   void read();
   void makeBase();
   /* 0 on success */
-- 
2.15.0

RE: Cygwin on Win10 much slower than Win7

[Nellis, Kenneth]

From: Stephen John Smoogen
> Sent: Thursday, November 2, 2017 12:49
> To: cygwin@cygwin.com
> Subject: Re: Cygwin on Win10 much slower than Win7
> 
> On 2 November 2017 at 12:44, Nellis, Kenneth 
> wrote:
> > From: cyg Simple
> >> On 11/2/2017 9:36 AM, Erik Bray wrote:
> >> > On Wed, Nov 1, 2017 at 3:50 PM, Nellis, Kenneth wrote:
> >> >> Since migrating from a Windows 7 laptop to one with Windows 10,
> >> >> I've noticed a significant speed decrease in opening a mintty/bash
> >> >> window from about 0.5s to 3.5s.
> >> >>
> >> >> I've narrowed it down to two bottlenecks in .bash_profile:
> >> >> to "cygpath" and "source".
> >> >>
> >> >> Each invocation of cygpath on Win10 takes about 0.12s while on
> >> >> Win7 takes only 0.016s. Both are running 64-bit Cygwin 2.9.0, and
> >> >> cygpath version 2.9.0.
> >> >>
> >> >> The files being sourced are the same, but for example, one file,
> >> >> .bash_aliases, only contains alias statements and a few variable
> >> >> assignments. On Win7, "time" says it takes 0.000s, but on Win10 it
> >> >> takes 0.023s.
> >> >>
> >> >> The Win7 CPU is "i7-4600M @ 2.90 GHz 2.90 GHz" while the
> >> >> Win10 CPU is "i7-6600U @ 2.60 GHz 2.81 GHz". I can't imagine this
> >> >> difference accounts for a 10x speed difference. Also the
> >> >> Win10 machine has an SSD compared to the Win7 machine's SCSI hard
> >> >> disk, which would favor the Win10 machine.
> >> >>
> >> >> I was wondering if anyone else noticed such a thing or could
> >> >> account for this speed difference. Can I simply blame Windows 10?
> >> >
> >> > There could be a real issue here, but for what it's worth I haven't
> >> > noticed such extreme slowdown.  But I don't have a Windows 7
> >> > machine to compare to.  I upgrade the one I'm on now from Windows 7
> >> > to Windows
> >> > 10 over a year ago, so if there ever was a difference maybe I just
> >> > got use to it and didn't notice.
> >> >
> >>
> >> Maybe a network drive connection timeout issue.  Are all of the
> >> drives that were mapped in Win7 still reachable in Win10?
> >>
> >> > I don't recall any major issues when I first upgraded either though
> >> > ¯\_(ツ)_/¯
> >> >
> >>
> >> I don't recall any either.
> >>
> >> --
> >> cyg Simple
> >
> > Yes, I dismounted all but one and same network drive on both machines,
> > and got the same results. The (faster) Win7 machine's network drive is
> > connected over WiFi while the (slower) Win10 machine over Gbit
> > Ethernet, which would seem to favor the slower machine. I hadn't
> > mentioned that the timing tests were all performed on my internal C:
> > drives, so don't think that network drives would be a factor.
> 
> One thing that might also help is how to duplicate what you are testing.
> Even without having network drives etc it could be useful for people to
> see if they are seeing speed differences or if there is something else.

I first noticed the problem with cygpath:
On Win 7:

$ time cygpath abc
abc

real0m0.016s
user0m0.000s
sys 0m0.015s
$

On Win 10:

$ time cygpath abc
abc

real0m0.105s
user0m0.000s
sys 0m0.062s
$

--Ken Nellis

--
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: [PATCH 1/2] posix_fadvise() *returns* error codes but does not set errno

[Corinna Vinschen]

On Nov  2 16:45, Erik M. Bray wrote:
> Also updates the fhandler_*::fadvise implementations to adhere to the same
> semantics.

Both patches pushed.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

[newlib-cygwin] posix_fallocate() *returns* error codes but does not set errno

[Corinna Vinschen]

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

commit 94854321bb79603b3adcf42093031c7e85c81e0a
Author: Erik M. Bray 
Date:   Thu Nov 2 16:45:35 2017 +0100

posix_fallocate() *returns* error codes but does not set errno

Also updates the fhandler_*::ftruncate implementations to adhere to the same
semantics.  The error handling semantics of those syscalls that use
fhandler_*::ftruncate are moved to the implementations of those syscalls (
in particular ftruncate() and friends still set errno and return -1 on error
but that logic is handled in the syscall implementation).

Diff:
---
 winsup/cygwin/fhandler.cc   |  3 +--
 winsup/cygwin/fhandler_disk_file.cc | 17 ++---
 winsup/cygwin/pipe.cc   |  3 +--
 winsup/cygwin/syscalls.cc   | 11 ---
 4 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index d719b7c..5b7d002 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -1771,8 +1771,7 @@ fhandler_base::fadvise (off_t offset, off_t length, int 
advice)
 int
 fhandler_base::ftruncate (off_t length, bool allow_truncate)
 {
-  set_errno (EINVAL);
-  return -1;
+  return EINVAL;
 }
 
 int
diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 252dc66..bc8fead 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1112,14 +1112,14 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
length, int advice)
 int
 fhandler_disk_file::ftruncate (off_t length, bool allow_truncate)
 {
-  int res = -1;
+  int res = 0;
 
   if (length < 0 || !get_handle ())
-set_errno (EINVAL);
+res = EINVAL;
   else if (pc.isdir ())
-set_errno (EISDIR);
+res = EISDIR;
   else if (!(get_access () & GENERIC_WRITE))
-set_errno (EBADF);
+res = EBADF;
   else
 {
   NTSTATUS status;
@@ -1130,10 +1130,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
   status = NtQueryInformationFile (get_handle (), , , sizeof fsi,
   FileStandardInformation);
   if (!NT_SUCCESS (status))
-   {
- __seterrno_from_nt_status (status);
- return -1;
-   }
+   return geterrno_from_nt_status (status);
 
   /* If called through posix_fallocate, silently succeed if length
 is less than the file's actual length. */
@@ -1159,9 +1156,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
 , sizeof feofi,
 FileEndOfFileInformation);
   if (!NT_SUCCESS (status))
-   __seterrno_from_nt_status (status);
-  else
-   res = 0;
+   res = geterrno_from_nt_status (status);
 }
   return res;
 }
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 8738d34..f1eace6 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -171,8 +171,7 @@ fhandler_pipe::fadvise (off_t offset, off_t length, int 
advice)
 int
 fhandler_pipe::ftruncate (off_t length, bool allow_truncate)
 {
-  set_errno (allow_truncate ? EINVAL : ESPIPE);
-  return -1;
+  return allow_truncate ? EINVAL : ESPIPE;
 }
 
 char *
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index d0d735b..1807afc 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2946,16 +2946,16 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
advice)
 extern "C" int
 posix_fallocate (int fd, off_t offset, off_t len)
 {
-  int res = -1;
+  int res = 0;
   if (offset < 0 || len == 0)
-set_errno (EINVAL);
+res = EINVAL;
   else
 {
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
res = cfd->ftruncate (offset + len, false);
   else
-   set_errno (EBADF);
+   res = EBADF;
 }
   syscall_printf ("%R = posix_fallocate(%d, %D, %D)", res, fd, offset, len);
   return res;
@@ -2968,6 +2968,11 @@ ftruncate64 (int fd, off_t length)
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
 res = cfd->ftruncate (length, true);
+if (res)
+  {
+set_errno (res);
+res = -1;
+  }
   else
 set_errno (EBADF);
   syscall_printf ("%R = ftruncate(%d, %D)", res, fd, length);

[newlib-cygwin] cygwin: add 2.9.1 release messages file

[Corinna Vinschen]

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

commit 09d60f64441ab1e9c7c6fede7abcc6ee9019a1e5
Author: Corinna Vinschen 
Date:   Thu Nov 2 18:09:39 2017 +0100

cygwin: add 2.9.1 release messages file

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.9.1 | 16 
 1 file changed, 16 insertions(+)

diff --git a/winsup/cygwin/release/2.9.1 b/winsup/cygwin/release/2.9.1
new file mode 100644
index 000..0a04b2a
--- /dev/null
+++ b/winsup/cygwin/release/2.9.1
@@ -0,0 +1,16 @@
+What's new:
+---
+
+
+What changed:
+-
+
+
+Bug Fixes
+-
+
+- Fix a problem in unlink on NFS.
+  Addresses: Shows up in GAWK testsuite test "testext"
+
+- Fix errno setting bug in posix_fadvise and posix_fallocate.
+  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q4/msg00026.html

[newlib-cygwin] posix_fadvise() *returns* error codes but does not set errno

[Corinna Vinschen]

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

commit 8c8cdd9ad72b07c1edefb5264cdcb4927700e813
Author: Erik M. Bray 
Date:   Thu Nov 2 16:45:34 2017 +0100

posix_fadvise() *returns* error codes but does not set errno

Also updates the fhandler_*::fadvise implementations to adhere to the same
semantics.

Diff:
---
 winsup/cygwin/fhandler_disk_file.cc | 11 +++
 winsup/cygwin/pipe.cc   |  3 +--
 winsup/cygwin/syscalls.cc   |  2 +-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 2144a4c..252dc66 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1075,10 +1075,7 @@ int
 fhandler_disk_file::fadvise (off_t offset, off_t length, int advice)
 {
   if (advice < POSIX_FADV_NORMAL || advice > POSIX_FADV_NOREUSE)
-{
-  set_errno (EINVAL);
-  return -1;
-}
+return EINVAL;
 
   /* Windows only supports advice flags for the whole file.  We're using
  a simplified test here so that we don't have to ask for the actual
@@ -1097,9 +1094,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t length, 
int advice)
   NTSTATUS status = NtQueryInformationFile (get_handle (), ,
, sizeof fmi,
FileModeInformation);
-  if (!NT_SUCCESS (status))
-__seterrno_from_nt_status (status);
-  else
+  if (NT_SUCCESS (status))
 {
   fmi.Mode &= ~FILE_SEQUENTIAL_ONLY;
   if (advice == POSIX_FADV_SEQUENTIAL)
@@ -,7 +1106,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t length, 
int advice)
   __seterrno_from_nt_status (status);
 }
 
-  return -1;
+  return geterrno_from_nt_status (status);
 }
 
 int
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 79b7966..8738d34 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -165,8 +165,7 @@ fhandler_pipe::lseek (off_t offset, int whence)
 int
 fhandler_pipe::fadvise (off_t offset, off_t length, int advice)
 {
-  set_errno (ESPIPE);
-  return -1;
+  return ESPIPE;
 }
 
 int
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index caa3a77..d0d735b 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2937,7 +2937,7 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
advice)
   if (cfd >= 0)
 res = cfd->fadvise (offset, len, advice);
   else
-set_errno (EBADF);
+res = EBADF;
   syscall_printf ("%R = posix_fadvice(%d, %D, %D, %d)",
  res, fd, offset, len, advice);
   return res;

Re: Cygwin on Win10 much slower than Win7

[Stephen John Smoogen]

On 2 November 2017 at 12:44, Nellis, Kenneth
 wrote:
> From: cyg Simple
>> On 11/2/2017 9:36 AM, Erik Bray wrote:
>> > On Wed, Nov 1, 2017 at 3:50 PM, Nellis, Kenneth wrote:
>> >> Since migrating from a Windows 7 laptop to one with Windows 10, I've
>> >> noticed a significant speed decrease in opening a mintty/bash window
>> >> from about 0.5s to 3.5s.
>> >>
>> >> I've narrowed it down to two bottlenecks in .bash_profile:
>> >> to "cygpath" and "source".
>> >>
>> >> Each invocation of cygpath on Win10 takes about 0.12s while on Win7
>> >> takes only 0.016s. Both are running 64-bit Cygwin 2.9.0, and cygpath
>> >> version 2.9.0.
>> >>
>> >> The files being sourced are the same, but for example, one file,
>> >> .bash_aliases, only contains alias statements and a few variable
>> >> assignments. On Win7, "time" says it takes 0.000s, but on Win10 it
>> >> takes 0.023s.
>> >>
>> >> The Win7 CPU is "i7-4600M @ 2.90 GHz 2.90 GHz" while the
>> >> Win10 CPU is "i7-6600U @ 2.60 GHz 2.81 GHz". I can't imagine this
>> >> difference accounts for a 10x speed difference. Also the
>> >> Win10 machine has an SSD compared to the Win7 machine's SCSI hard
>> >> disk, which would favor the Win10 machine.
>> >>
>> >> I was wondering if anyone else noticed such a thing or could account
>> >> for this speed difference. Can I simply blame Windows 10?
>> >
>> > There could be a real issue here, but for what it's worth I haven't
>> > noticed such extreme slowdown.  But I don't have a Windows 7 machine
>> > to compare to.  I upgrade the one I'm on now from Windows 7 to Windows
>> > 10 over a year ago, so if there ever was a difference maybe I just got
>> > use to it and didn't notice.
>> >
>>
>> Maybe a network drive connection timeout issue.  Are all of the drives
>> that were mapped in Win7 still reachable in Win10?
>>
>> > I don't recall any major issues when I first upgraded either though
>> > ¯\_(ツ)_/¯
>> >
>>
>> I don't recall any either.
>>
>> --
>> cyg Simple
>
> Yes, I dismounted all but one and same network drive on both machines,
> and got the same results. The (faster) Win7 machine's network drive is
> connected over WiFi while the (slower) Win10 machine over Gbit Ethernet,
> which would seem to favor the slower machine. I hadn't mentioned that
> the timing tests were all performed on my internal C: drives, so don't
> think that network drives would be a factor.

One thing that might also help is how to duplicate what you are
testing. Even without having network drives etc it could be useful for
people to see if they are seeing speed differences or if there is
something else.


> --Ken Nellis
>



-- 
Stephen J Smoogen.

--
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: Cygwin on Win10 much slower than Win7

[Nellis, Kenneth]

From: cyg Simple
> On 11/2/2017 9:36 AM, Erik Bray wrote:
> > On Wed, Nov 1, 2017 at 3:50 PM, Nellis, Kenneth wrote:
> >> Since migrating from a Windows 7 laptop to one with Windows 10, I've
> >> noticed a significant speed decrease in opening a mintty/bash window
> >> from about 0.5s to 3.5s.
> >>
> >> I've narrowed it down to two bottlenecks in .bash_profile:
> >> to "cygpath" and "source".
> >>
> >> Each invocation of cygpath on Win10 takes about 0.12s while on Win7
> >> takes only 0.016s. Both are running 64-bit Cygwin 2.9.0, and cygpath
> >> version 2.9.0.
> >>
> >> The files being sourced are the same, but for example, one file,
> >> .bash_aliases, only contains alias statements and a few variable
> >> assignments. On Win7, "time" says it takes 0.000s, but on Win10 it
> >> takes 0.023s.
> >>
> >> The Win7 CPU is "i7-4600M @ 2.90 GHz 2.90 GHz" while the
> >> Win10 CPU is "i7-6600U @ 2.60 GHz 2.81 GHz". I can't imagine this
> >> difference accounts for a 10x speed difference. Also the
> >> Win10 machine has an SSD compared to the Win7 machine's SCSI hard
> >> disk, which would favor the Win10 machine.
> >>
> >> I was wondering if anyone else noticed such a thing or could account
> >> for this speed difference. Can I simply blame Windows 10?
> >
> > There could be a real issue here, but for what it's worth I haven't
> > noticed such extreme slowdown.  But I don't have a Windows 7 machine
> > to compare to.  I upgrade the one I'm on now from Windows 7 to Windows
> > 10 over a year ago, so if there ever was a difference maybe I just got
> > use to it and didn't notice.
> >
> 
> Maybe a network drive connection timeout issue.  Are all of the drives
> that were mapped in Win7 still reachable in Win10?
> 
> > I don't recall any major issues when I first upgraded either though
> > ¯\_(ツ)_/¯
> >
> 
> I don't recall any either.
> 
> --
> cyg Simple

Yes, I dismounted all but one and same network drive on both machines, 
and got the same results. The (faster) Win7 machine's network drive is 
connected over WiFi while the (slower) Win10 machine over Gbit Ethernet, 
which would seem to favor the slower machine. I hadn't mentioned that 
the timing tests were all performed on my internal C: drives, so don't 
think that network drives would be a factor.

--Ken Nellis 

Re: Proper way to run emacs from desktop

[Jon Turney]

On 01/11/2017 21:57, David Karr wrote:

On Wed, Nov 1, 2017 at 12:57 PM, Ken Brown  wrote:

On 11/1/2017 1:08 PM, David Karr wrote:

I install Cygwin every couple of years and then use it continuously
without updates between those installations.  I installed it on a new
laptop today, and I'm trying to work through issues.

The current issue is running Emacs from the desktop.

I had a shortcut working for a long time that does the following:
-
C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 /usr/local/bin/emacs.xml
-


Just '--display :0.0' is probably better, as it won't stop working when 
the Xserver is run without '-listen tcp'...



The "run2" application doesn't appear to exist.  I checked my notes,
and I can't tell whether I installed this from somewhere else the last
time I did this.


Just install the run2 package.  It's still available.


Ok.  I find the search facility in setup somewhat confusing.  I
couldn't find it before. I found it now, and I've installed it.


You can also search using e.g. 
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=run2.exe=x86_64



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

[PATCH 1/2] posix_fadvise() *returns* error codes but does not set errno

[Erik M. Bray]

Also updates the fhandler_*::fadvise implementations to adhere to the same
semantics.
---
 winsup/cygwin/fhandler_disk_file.cc | 11 +++
 winsup/cygwin/pipe.cc   |  3 +--
 winsup/cygwin/syscalls.cc   |  2 +-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 2144a4c..252dc66 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1075,10 +1075,7 @@ int
 fhandler_disk_file::fadvise (off_t offset, off_t length, int advice)
 {
   if (advice < POSIX_FADV_NORMAL || advice > POSIX_FADV_NOREUSE)
-{
-  set_errno (EINVAL);
-  return -1;
-}
+return EINVAL;
 
   /* Windows only supports advice flags for the whole file.  We're using
  a simplified test here so that we don't have to ask for the actual
@@ -1097,9 +1094,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t length, 
int advice)
   NTSTATUS status = NtQueryInformationFile (get_handle (), ,
, sizeof fmi,
FileModeInformation);
-  if (!NT_SUCCESS (status))
-__seterrno_from_nt_status (status);
-  else
+  if (NT_SUCCESS (status))
 {
   fmi.Mode &= ~FILE_SEQUENTIAL_ONLY;
   if (advice == POSIX_FADV_SEQUENTIAL)
@@ -,7 +1106,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t length, 
int advice)
   __seterrno_from_nt_status (status);
 }
 
-  return -1;
+  return geterrno_from_nt_status (status);
 }
 
 int
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 79b7966..8738d34 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -165,8 +165,7 @@ fhandler_pipe::lseek (off_t offset, int whence)
 int
 fhandler_pipe::fadvise (off_t offset, off_t length, int advice)
 {
-  set_errno (ESPIPE);
-  return -1;
+  return ESPIPE;
 }
 
 int
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index caa3a77..d0d735b 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2937,7 +2937,7 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
advice)
   if (cfd >= 0)
 res = cfd->fadvise (offset, len, advice);
   else
-set_errno (EBADF);
+res = EBADF;
   syscall_printf ("%R = posix_fadvice(%d, %D, %D, %d)",
  res, fd, offset, len, advice);
   return res;
-- 
2.8.3

[PATCH 2/2] posix_fallocate() *returns* error codes but does not set errno

[Erik M. Bray]

Also updates the fhandler_*::ftruncate implementations to adhere to the same
semantics.  The error handling semantics of those syscalls that use
fhandler_*::ftruncate are moved to the implementations of those syscalls (
in particular ftruncate() and friends still set errno and return -1 on error
but that logic is handled in the syscall implementation).
---
 winsup/cygwin/fhandler.cc   |  3 +--
 winsup/cygwin/fhandler_disk_file.cc | 17 ++---
 winsup/cygwin/pipe.cc   |  3 +--
 winsup/cygwin/syscalls.cc   | 11 ---
 4 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index d719b7c..5b7d002 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -1771,8 +1771,7 @@ fhandler_base::fadvise (off_t offset, off_t length, int 
advice)
 int
 fhandler_base::ftruncate (off_t length, bool allow_truncate)
 {
-  set_errno (EINVAL);
-  return -1;
+  return EINVAL;
 }
 
 int
diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 252dc66..bc8fead 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1112,14 +1112,14 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
length, int advice)
 int
 fhandler_disk_file::ftruncate (off_t length, bool allow_truncate)
 {
-  int res = -1;
+  int res = 0;
 
   if (length < 0 || !get_handle ())
-set_errno (EINVAL);
+res = EINVAL;
   else if (pc.isdir ())
-set_errno (EISDIR);
+res = EISDIR;
   else if (!(get_access () & GENERIC_WRITE))
-set_errno (EBADF);
+res = EBADF;
   else
 {
   NTSTATUS status;
@@ -1130,10 +1130,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
   status = NtQueryInformationFile (get_handle (), , , sizeof fsi,
   FileStandardInformation);
   if (!NT_SUCCESS (status))
-   {
- __seterrno_from_nt_status (status);
- return -1;
-   }
+   return geterrno_from_nt_status (status);
 
   /* If called through posix_fallocate, silently succeed if length
 is less than the file's actual length. */
@@ -1159,9 +1156,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
 , sizeof feofi,
 FileEndOfFileInformation);
   if (!NT_SUCCESS (status))
-   __seterrno_from_nt_status (status);
-  else
-   res = 0;
+   res = geterrno_from_nt_status (status);
 }
   return res;
 }
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 8738d34..f1eace6 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -171,8 +171,7 @@ fhandler_pipe::fadvise (off_t offset, off_t length, int 
advice)
 int
 fhandler_pipe::ftruncate (off_t length, bool allow_truncate)
 {
-  set_errno (allow_truncate ? EINVAL : ESPIPE);
-  return -1;
+  return allow_truncate ? EINVAL : ESPIPE;
 }
 
 char *
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index d0d735b..1807afc 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2946,16 +2946,16 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
advice)
 extern "C" int
 posix_fallocate (int fd, off_t offset, off_t len)
 {
-  int res = -1;
+  int res = 0;
   if (offset < 0 || len == 0)
-set_errno (EINVAL);
+res = EINVAL;
   else
 {
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
res = cfd->ftruncate (offset + len, false);
   else
-   set_errno (EBADF);
+   res = EBADF;
 }
   syscall_printf ("%R = posix_fallocate(%d, %D, %D)", res, fd, offset, len);
   return res;
@@ -2968,6 +2968,11 @@ ftruncate64 (int fd, off_t length)
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
 res = cfd->ftruncate (length, true);
+if (res)
+  {
+set_errno (res);
+res = -1;
+  }
   else
 set_errno (EBADF);
   syscall_printf ("%R = ftruncate(%d, %D)", res, fd, length);
-- 
2.8.3

Re: [PATCH 2/2] posix_fallocate() *returns* error codes but does not set errno

[Erik Bray]

On Thu, Nov 2, 2017 at 4:06 PM, Corinna Vinschen wrote:
> Hi Erik,
>
> On Nov  2 15:15, Erik M. Bray wrote:
>> diff --git a/winsup/cygwin/fhandler_disk_file.cc 
>> b/winsup/cygwin/fhandler_disk_file.cc
>> index f46e355..9d5ec30 100644
>> --- a/winsup/cygwin/fhandler_disk_file.cc
>> +++ b/winsup/cygwin/fhandler_disk_file.cc
>> @@ -1116,11 +1116,11 @@ fhandler_disk_file::ftruncate (off_t length, bool 
>> allow_truncate)
>>int res = -1;
>
> Shouldn't this initialization to -1 go away then?  Or set to 0 and...
>
>> @@ -1160,7 +1159,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
>> allow_truncate)
>>, sizeof feofi,
>>FileEndOfFileInformation);
>>if (!NT_SUCCESS (status))
>> - __seterrno_from_nt_status (status);
>> + res = geterrno_from_nt_status (status);
>>else
>>   res = 0;
>
> ...this else branch go away like you did in posix_fallocate?

Yes, I think you're right.  I'll rework this and the other patch per
your suggestions and re-post.

Thanks for the quick review,
Erik

Re: Setup's local package directory on network share

[Andrey Repin]

Greetings, Aaron Digulla!

> I would like to share the local package cache with other people.

> When browse folders in the respective page in setup.exe, no network shares 
> are visible.

> When I manually enter the path (using a mapped drive), I get a dialog:
> "Directory S:\cygwin\Downloads does not exist, would you like me to create
> it?" which is wrong since the folder exists.

No, it isn't wrong, since you are using mapped drive, which may not exist in a
different user session.
There's an easy solution, though: stop using mapped drives. You should have
been, for 17 years now.

> When I click "yes", I get an error "Couldn't create directory. Is drive full 
> or read-only?"

> I can create a folder (and delete it) from Explorer, so it's not a Windows 
> permission problem.

> What is the problem here? I searched the documentation and it mentions a
> couple of problems with network shares and Windows authentication but that 
> when Cygwin is already running.

Store setup.exe on the same network share and use UNC path to access it.
Then "other people" could use both a fresh package cache and a fresh setup.exe
together.
You can even restrict write access to the share, if desired, then "other
people" could use it to install from downloaded archives, and selected
administrators with write access could refresh package archive.


-- 
With best regards,
Andrey Repin
Thursday, November 2, 2017 18:10:02

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: [PATCH] posix_fadvise() *returns* error codes but does not set errno

[Erik Bray]

On Thu, Nov 2, 2017 at 3:58 PM, Corinna Vinschen
 wrote:
> Hi Eric,
>
> On Nov  2 14:26, Erik M. Bray wrote:
>> Also updates the fhandler_*::fadvise implementations to adhere to the same
>> semantics.
>
> Good catch.  I have just some style nits.
>
>> ---
>>  winsup/cygwin/fhandler.cc   |  3 +--
>>  winsup/cygwin/fhandler_disk_file.cc | 16 ++--
>>  winsup/cygwin/pipe.cc   |  3 +--
>>  winsup/cygwin/syscalls.cc   |  2 +-
>>  4 files changed, 9 insertions(+), 15 deletions(-)
>>
>> diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
>> index d719b7c..858c1fd 100644
>> --- a/winsup/cygwin/fhandler.cc
>> +++ b/winsup/cygwin/fhandler.cc
>> @@ -1764,8 +1764,7 @@ fhandler_base::fsetxattr (const char *name, const void 
>> *value, size_t size,
>>  int
>>  fhandler_base::fadvise (off_t offset, off_t length, int advice)
>>  {
>> -  set_errno (EINVAL);
>> -  return -1;
>> +  return EINVAL;
>>  }
>>
>>  int
>> diff --git a/winsup/cygwin/fhandler_disk_file.cc 
>> b/winsup/cygwin/fhandler_disk_file.cc
>> index 2144a4c..f46e355 100644
>> --- a/winsup/cygwin/fhandler_disk_file.cc
>> +++ b/winsup/cygwin/fhandler_disk_file.cc
>> @@ -1076,8 +1076,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
>> length, int advice)
>>  {
>>if (advice < POSIX_FADV_NORMAL || advice > POSIX_FADV_NOREUSE)
>>  {
>> -  set_errno (EINVAL);
>> -  return -1;
>> +  return EINVAL;
>>  }
>
> Please remove the braces for a one-line block.
>
>>
>>/* Windows only supports advice flags for the whole file.  We're using
>> @@ -1097,21 +1096,18 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
>> length, int advice)
>>NTSTATUS status = NtQueryInformationFile (get_handle (), ,
>>   , sizeof fmi,
>>   FileModeInformation);
>> -  if (!NT_SUCCESS (status))
>> -__seterrno_from_nt_status (status);
>> -  else
>> +  if (NT_SUCCESS (status))
>>  {
>>fmi.Mode &= ~FILE_SEQUENTIAL_ONLY;
>>if (advice == POSIX_FADV_SEQUENTIAL)
>> - fmi.Mode |= FILE_SEQUENTIAL_ONLY;
>> +fmi.Mode |= FILE_SEQUENTIAL_ONLY;
>
> You changed indentation here for no apparent reason (TABs vs spaces).

Sorry, it's just that the indentation in this function is already an
unholy mess of tabs vs spaces from line to line.  This was just my
editor's (ill-advised) attempt to make it legible.  I can remove the
unrelated whitespace changes from the patch.

>>status = NtSetInformationFile (get_handle (), , , sizeof fmi,
>> -  FileModeInformation);
>> + FileModeInformation);
>>if (NT_SUCCESS (status))
>> - return 0;
>> -  __seterrno_from_nt_status (status);
>> + return 0;
>>  }
>
> Ditto and ditto.
>
>> -  return -1;
>> +  return geterrno_from_nt_status (status);
>>  }
>>
>>  int
>> diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
>> index 79b7966..8738d34 100644
>> --- a/winsup/cygwin/pipe.cc
>> +++ b/winsup/cygwin/pipe.cc
>> @@ -165,8 +165,7 @@ fhandler_pipe::lseek (off_t offset, int whence)
>>  int
>>  fhandler_pipe::fadvise (off_t offset, off_t length, int advice)
>>  {
>> -  set_errno (ESPIPE);
>> -  return -1;
>> +  return ESPIPE;
>>  }
>>
>>  int
>> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
>> index caa3a77..d0d735b 100644
>> --- a/winsup/cygwin/syscalls.cc
>> +++ b/winsup/cygwin/syscalls.cc
>> @@ -2937,7 +2937,7 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
>> advice)
>>if (cfd >= 0)
>>  res = cfd->fadvise (offset, len, advice);
>>else
>> -set_errno (EBADF);
>> +res = EBADF;
>>syscall_printf ("%R = posix_fadvice(%d, %D, %D, %d)",
>> res, fd, offset, len, advice);
>>return res;
>> --
>> 2.8.3
>
> Other than that, looks good.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Re: [PATCH] posix_fadvise() *returns* error codes but does not set errno

[Corinna Vinschen]

On Nov  2 15:58, Corinna Vinschen wrote:
> Hi Eric,

s/Eric/Erik/


Sorry,
Corinna

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


signature.asc
Description: PGP signature

Re: [PATCH 2/2] posix_fallocate() *returns* error codes but does not set errno

[Corinna Vinschen]

Hi Erik,

On Nov  2 15:15, Erik M. Bray wrote:
> diff --git a/winsup/cygwin/fhandler_disk_file.cc 
> b/winsup/cygwin/fhandler_disk_file.cc
> index f46e355..9d5ec30 100644
> --- a/winsup/cygwin/fhandler_disk_file.cc
> +++ b/winsup/cygwin/fhandler_disk_file.cc
> @@ -1116,11 +1116,11 @@ fhandler_disk_file::ftruncate (off_t length, bool 
> allow_truncate)
>int res = -1;

Shouldn't this initialization to -1 go away then?  Or set to 0 and...

> @@ -1160,7 +1159,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
> allow_truncate)
>, sizeof feofi,
>FileEndOfFileInformation);
>if (!NT_SUCCESS (status))
> - __seterrno_from_nt_status (status);
> + res = geterrno_from_nt_status (status);
>else
>   res = 0;

...this else branch go away like you did in posix_fallocate?


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: [PATCH] posix_fadvise() *returns* error codes but does not set errno

[Corinna Vinschen]

Hi Eric,

On Nov  2 14:26, Erik M. Bray wrote:
> Also updates the fhandler_*::fadvise implementations to adhere to the same
> semantics.

Good catch.  I have just some style nits.

> ---
>  winsup/cygwin/fhandler.cc   |  3 +--
>  winsup/cygwin/fhandler_disk_file.cc | 16 ++--
>  winsup/cygwin/pipe.cc   |  3 +--
>  winsup/cygwin/syscalls.cc   |  2 +-
>  4 files changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
> index d719b7c..858c1fd 100644
> --- a/winsup/cygwin/fhandler.cc
> +++ b/winsup/cygwin/fhandler.cc
> @@ -1764,8 +1764,7 @@ fhandler_base::fsetxattr (const char *name, const void 
> *value, size_t size,
>  int
>  fhandler_base::fadvise (off_t offset, off_t length, int advice)
>  {
> -  set_errno (EINVAL);
> -  return -1;
> +  return EINVAL;
>  }
>  
>  int
> diff --git a/winsup/cygwin/fhandler_disk_file.cc 
> b/winsup/cygwin/fhandler_disk_file.cc
> index 2144a4c..f46e355 100644
> --- a/winsup/cygwin/fhandler_disk_file.cc
> +++ b/winsup/cygwin/fhandler_disk_file.cc
> @@ -1076,8 +1076,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
> length, int advice)
>  {
>if (advice < POSIX_FADV_NORMAL || advice > POSIX_FADV_NOREUSE)
>  {
> -  set_errno (EINVAL);
> -  return -1;
> +  return EINVAL;
>  }

Please remove the braces for a one-line block.

>  
>/* Windows only supports advice flags for the whole file.  We're using
> @@ -1097,21 +1096,18 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
> length, int advice)
>NTSTATUS status = NtQueryInformationFile (get_handle (), ,
>   , sizeof fmi,
>   FileModeInformation);
> -  if (!NT_SUCCESS (status))
> -__seterrno_from_nt_status (status);
> -  else
> +  if (NT_SUCCESS (status))
>  {
>fmi.Mode &= ~FILE_SEQUENTIAL_ONLY;
>if (advice == POSIX_FADV_SEQUENTIAL)
> - fmi.Mode |= FILE_SEQUENTIAL_ONLY;
> +fmi.Mode |= FILE_SEQUENTIAL_ONLY;

You changed indentation here for no apparent reason (TABs vs spaces).

>status = NtSetInformationFile (get_handle (), , , sizeof fmi,
> -  FileModeInformation);
> + FileModeInformation);
>if (NT_SUCCESS (status))
> - return 0;
> -  __seterrno_from_nt_status (status);
> + return 0;
>  }

Ditto and ditto.

> -  return -1;
> +  return geterrno_from_nt_status (status);
>  }
>  
>  int
> diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
> index 79b7966..8738d34 100644
> --- a/winsup/cygwin/pipe.cc
> +++ b/winsup/cygwin/pipe.cc
> @@ -165,8 +165,7 @@ fhandler_pipe::lseek (off_t offset, int whence)
>  int
>  fhandler_pipe::fadvise (off_t offset, off_t length, int advice)
>  {
> -  set_errno (ESPIPE);
> -  return -1;
> +  return ESPIPE;
>  }
>  
>  int
> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
> index caa3a77..d0d735b 100644
> --- a/winsup/cygwin/syscalls.cc
> +++ b/winsup/cygwin/syscalls.cc
> @@ -2937,7 +2937,7 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
> advice)
>if (cfd >= 0)
>  res = cfd->fadvise (offset, len, advice);
>else
> -set_errno (EBADF);
> +res = EBADF;
>syscall_printf ("%R = posix_fadvice(%d, %D, %D, %d)",
> res, fd, offset, len, advice);
>return res;
> -- 
> 2.8.3

Other than that, looks good.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

[PATCH 2/2] posix_fallocate() *returns* error codes but does not set errno

[Erik M. Bray]

Also updates the fhandler_*::ftruncate implementations to adhere to the same
semantics.  The error handling semantics of those syscalls that use
fhandler_*::ftruncate are moved to the implementations of those syscalls (
in particular ftruncate() and friends still set errno and return -1 on error
but that logic is handled in the syscall implementation).
---
 winsup/cygwin/fhandler.cc   |  3 +--
 winsup/cygwin/fhandler_disk_file.cc | 11 +--
 winsup/cygwin/pipe.cc   |  3 +--
 winsup/cygwin/syscalls.cc   | 11 ---
 4 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index 858c1fd..109bf4e 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -1770,8 +1770,7 @@ fhandler_base::fadvise (off_t offset, off_t length, int 
advice)
 int
 fhandler_base::ftruncate (off_t length, bool allow_truncate)
 {
-  set_errno (EINVAL);
-  return -1;
+  return EINVAL;
 }
 
 int
diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index f46e355..9d5ec30 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1116,11 +1116,11 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
   int res = -1;
 
   if (length < 0 || !get_handle ())
-set_errno (EINVAL);
+res = EINVAL;
   else if (pc.isdir ())
-set_errno (EISDIR);
+res = EISDIR;
   else if (!(get_access () & GENERIC_WRITE))
-set_errno (EBADF);
+res = EBADF;
   else
 {
   NTSTATUS status;
@@ -1132,8 +1132,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
   FileStandardInformation);
   if (!NT_SUCCESS (status))
{
- __seterrno_from_nt_status (status);
- return -1;
+ return geterrno_from_nt_status (status);
}
 
   /* If called through posix_fallocate, silently succeed if length
@@ -1160,7 +1159,7 @@ fhandler_disk_file::ftruncate (off_t length, bool 
allow_truncate)
 , sizeof feofi,
 FileEndOfFileInformation);
   if (!NT_SUCCESS (status))
-   __seterrno_from_nt_status (status);
+   res = geterrno_from_nt_status (status);
   else
res = 0;
 }
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 8738d34..f1eace6 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -171,8 +171,7 @@ fhandler_pipe::fadvise (off_t offset, off_t length, int 
advice)
 int
 fhandler_pipe::ftruncate (off_t length, bool allow_truncate)
 {
-  set_errno (allow_truncate ? EINVAL : ESPIPE);
-  return -1;
+  return allow_truncate ? EINVAL : ESPIPE;
 }
 
 char *
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index d0d735b..1807afc 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2946,16 +2946,16 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
advice)
 extern "C" int
 posix_fallocate (int fd, off_t offset, off_t len)
 {
-  int res = -1;
+  int res = 0;
   if (offset < 0 || len == 0)
-set_errno (EINVAL);
+res = EINVAL;
   else
 {
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
res = cfd->ftruncate (offset + len, false);
   else
-   set_errno (EBADF);
+   res = EBADF;
 }
   syscall_printf ("%R = posix_fallocate(%d, %D, %D)", res, fd, offset, len);
   return res;
@@ -2968,6 +2968,11 @@ ftruncate64 (int fd, off_t length)
   cygheap_fdget cfd (fd);
   if (cfd >= 0)
 res = cfd->ftruncate (length, true);
+if (res)
+  {
+set_errno (res);
+res = -1;
+  }
   else
 set_errno (EBADF);
   syscall_printf ("%R = ftruncate(%d, %D)", res, fd, length);
-- 
2.8.3

Re: Setup's local package directory on network share

[Achim Gratz]

Am 02.11.2017 um 14:52 schrieb Aaron Digulla:

What is the problem here? I searched the documentation and it mentions a couple 
of problems with network shares
and Windows authentication but that when Cygwin is already running.


The problem most likely is that the (local?) administrator account that 
you run setup under has no access rights on that network share and/or 
the drive is not mapped for that account while setup is running.



--
Achim.

(on the road :-)


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

Setup's local package directory on network share

[Aaron Digulla]

Hello,

I would like to share the local package cache with other people.

When browse folders in the respective page in setup.exe, no network shares are 
visible.

When I manually enter the path (using a mapped drive), I get a dialog: 
"Directory S:\cygwin\Downloads does not exist, would you like me to create it?" 
which is wrong since the folder exists.

When I click "yes", I get an error "Couldn't create directory. Is drive full or 
read-only?"

I can create a folder (and delete it) from Explorer, so it's not a Windows 
permission problem.

What is the problem here? I searched the documentation and it mentions a couple 
of problems with network shares and Windows authentication but that when Cygwin 
is already running.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://blog.pdark.de/

--
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: Cygwin on Win10 much slower than Win7

[cyg Simple]

On 11/2/2017 9:36 AM, Erik Bray wrote:
> On Wed, Nov 1, 2017 at 3:50 PM, Nellis, Kenneth wrote:
>> Since migrating from a Windows 7 laptop to one with Windows
>> 10, I've noticed a significant speed decrease in opening a
>> mintty/bash window from about 0.5s to 3.5s.
>>
>> I've narrowed it down to two bottlenecks in .bash_profile:
>> to "cygpath" and "source".
>>
>> Each invocation of cygpath on Win10 takes about 0.12s while
>> on Win7 takes only 0.016s. Both are running 64-bit Cygwin
>> 2.9.0, and cygpath version 2.9.0.
>>
>> The files being sourced are the same, but for example, one
>> file, .bash_aliases, only contains alias statements and a
>> few variable assignments. On Win7, "time" says it takes
>> 0.000s, but on Win10 it takes 0.023s.
>>
>> The Win7 CPU is "i7-4600M @ 2.90 GHz 2.90 GHz" while the
>> Win10 CPU is "i7-6600U @ 2.60 GHz 2.81 GHz". I can't imagine
>> this difference accounts for a 10x speed difference. Also the
>> Win10 machine has an SSD compared to the Win7 machine's SCSI
>> hard disk, which would favor the Win10 machine.
>>
>> I was wondering if anyone else noticed such a thing or could
>> account for this speed difference. Can I simply blame Windows
>> 10?
> 
> There could be a real issue here, but for what it's worth I haven't
> noticed such extreme slowdown.  But I don't have a Windows 7 machine
> to compare to.  I upgrade the one I'm on now from Windows 7 to Windows
> 10 over a year ago, so if there ever was a difference maybe I just got
> use to it and didn't notice.
> 

Maybe a network drive connection timeout issue.  Are all of the drives
that were mapped in Win7 still reachable in Win10?

> I don't recall any major issues when I first upgraded either though  ¯\_(ツ)_/¯
> 

I don't recall any either.

-- 
cyg Simple

--
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: tcl / tcl-tk updates - two links going nowhere

[Marco Atzeri]

On 02/11/2017 13:46, Fergus wrote:

The recent updates
tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1
have induced two links
/lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh
/lib/tk8.6/tkConfig.sh -> ../tkConfig.sh
that lead nowhere. Is there a fix?
Thank you.
Fergus



install tcl-devel and tcl-tk-devel

--
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: Can I change the windows icon from command line?

[cyg Simple]

On 11/2/2017 2:47 AM, Thomas Wolff wrote:
> Thanks, Brian, for the links and the sample code which will make it easier.
> This is about changing the icon, to get that sorted out.
> I referred to changing the icon label (an existing sequence supported by
> xterm), i.e. the text shown in the taskbar, which cannot be changed in
> Windows as far as I know as it's always the same as the window title.

RXVT managed to change the title based on the xterm escape sequences.
I've used that idea for various server connections in the past with RXVT.

-- 
cyg Simple

--
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: Cygwin on Win10 much slower than Win7

[Erik Bray]

On Wed, Nov 1, 2017 at 3:50 PM, Nellis, Kenneth wrote:
> Since migrating from a Windows 7 laptop to one with Windows
> 10, I've noticed a significant speed decrease in opening a
> mintty/bash window from about 0.5s to 3.5s.
>
> I've narrowed it down to two bottlenecks in .bash_profile:
> to "cygpath" and "source".
>
> Each invocation of cygpath on Win10 takes about 0.12s while
> on Win7 takes only 0.016s. Both are running 64-bit Cygwin
> 2.9.0, and cygpath version 2.9.0.
>
> The files being sourced are the same, but for example, one
> file, .bash_aliases, only contains alias statements and a
> few variable assignments. On Win7, "time" says it takes
> 0.000s, but on Win10 it takes 0.023s.
>
> The Win7 CPU is "i7-4600M @ 2.90 GHz 2.90 GHz" while the
> Win10 CPU is "i7-6600U @ 2.60 GHz 2.81 GHz". I can't imagine
> this difference accounts for a 10x speed difference. Also the
> Win10 machine has an SSD compared to the Win7 machine's SCSI
> hard disk, which would favor the Win10 machine.
>
> I was wondering if anyone else noticed such a thing or could
> account for this speed difference. Can I simply blame Windows
> 10?

There could be a real issue here, but for what it's worth I haven't
noticed such extreme slowdown.  But I don't have a Windows 7 machine
to compare to.  I upgrade the one I'm on now from Windows 7 to Windows
10 over a year ago, so if there ever was a difference maybe I just got
use to it and didn't notice.

I don't recall any major issues when I first upgraded either though  ¯\_(ツ)_/¯

--
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: tcl / tcl-tk updates - two links going nowhere

[Fergus]

> The recent updates
> tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1
> have induced two links
> /lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh
> /lib/tk8.6/tkConfig.sh -> ../tkConfig.sh
> that lead nowhere. Is there a fix?

The two missing t*Config.sh files can be obtained by decompressing
tcl-devel-8.6.6-1.tar.xz
tcl-tk-devel-8.6.6-1.tar.xz
(These two files were not part of the original downloaded update.
Should they have been?)
Fergus

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

[PATCH] posix_fadvise() *returns* error codes but does not set errno

[Erik M. Bray]

Also updates the fhandler_*::fadvise implementations to adhere to the same
semantics.
---
 winsup/cygwin/fhandler.cc   |  3 +--
 winsup/cygwin/fhandler_disk_file.cc | 16 ++--
 winsup/cygwin/pipe.cc   |  3 +--
 winsup/cygwin/syscalls.cc   |  2 +-
 4 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index d719b7c..858c1fd 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -1764,8 +1764,7 @@ fhandler_base::fsetxattr (const char *name, const void 
*value, size_t size,
 int
 fhandler_base::fadvise (off_t offset, off_t length, int advice)
 {
-  set_errno (EINVAL);
-  return -1;
+  return EINVAL;
 }
 
 int
diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 2144a4c..f46e355 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1076,8 +1076,7 @@ fhandler_disk_file::fadvise (off_t offset, off_t length, 
int advice)
 {
   if (advice < POSIX_FADV_NORMAL || advice > POSIX_FADV_NOREUSE)
 {
-  set_errno (EINVAL);
-  return -1;
+  return EINVAL;
 }
 
   /* Windows only supports advice flags for the whole file.  We're using
@@ -1097,21 +1096,18 @@ fhandler_disk_file::fadvise (off_t offset, off_t 
length, int advice)
   NTSTATUS status = NtQueryInformationFile (get_handle (), ,
, sizeof fmi,
FileModeInformation);
-  if (!NT_SUCCESS (status))
-__seterrno_from_nt_status (status);
-  else
+  if (NT_SUCCESS (status))
 {
   fmi.Mode &= ~FILE_SEQUENTIAL_ONLY;
   if (advice == POSIX_FADV_SEQUENTIAL)
-   fmi.Mode |= FILE_SEQUENTIAL_ONLY;
+fmi.Mode |= FILE_SEQUENTIAL_ONLY;
   status = NtSetInformationFile (get_handle (), , , sizeof fmi,
-FileModeInformation);
+ FileModeInformation);
   if (NT_SUCCESS (status))
-   return 0;
-  __seterrno_from_nt_status (status);
+   return 0;
 }
 
-  return -1;
+  return geterrno_from_nt_status (status);
 }
 
 int
diff --git a/winsup/cygwin/pipe.cc b/winsup/cygwin/pipe.cc
index 79b7966..8738d34 100644
--- a/winsup/cygwin/pipe.cc
+++ b/winsup/cygwin/pipe.cc
@@ -165,8 +165,7 @@ fhandler_pipe::lseek (off_t offset, int whence)
 int
 fhandler_pipe::fadvise (off_t offset, off_t length, int advice)
 {
-  set_errno (ESPIPE);
-  return -1;
+  return ESPIPE;
 }
 
 int
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index caa3a77..d0d735b 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -2937,7 +2937,7 @@ posix_fadvise (int fd, off_t offset, off_t len, int 
advice)
   if (cfd >= 0)
 res = cfd->fadvise (offset, len, advice);
   else
-set_errno (EBADF);
+res = EBADF;
   syscall_printf ("%R = posix_fadvice(%d, %D, %D, %d)",
  res, fd, offset, len, advice);
   return res;
-- 
2.8.3

tcl / tcl-tk updates - two links going nowhere

[Fergus]

The recent updates
tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1
have induced two links
/lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh
/lib/tk8.6/tkConfig.sh -> ../tkConfig.sh
that lead nowhere. Is there a fix?
Thank you.
Fergus

--
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: ada gnat import library missing ?

[Arjen Markus]

Hello Marco, Jon,

good to hear this - I will try this updated GNU version within the
context of the PLplot project.

Regards,

Arjen

--
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: ada gnat import library missing ?

[Marco Atzeri]

On 02/11/2017 11:28, JonY wrote:

On 11/01/2017 04:07 PM, Marco Atzeri wrote:

On 31/10/2017 00:17, JonY wrote:


-2 with the appropriate import libraries should be coming along by the
end of the week if all goes well.


It is up but I see the same

$ ./hello.exe
  -bash: ./hello.exe: cannot execute binary file: Exec format error

Does it work for you ?



I think I solved the mystery, this generates a dll instead of an exe,
see the verbose output calling the compiler.



you are right; "-shared" should be used only on the 2nd step
not on the third.

$ gcc -c hello.adb

$ gnatbind -v -shared hello
gnatbind -v -shared hello
GNATBIND 6.4.0
Copyright (C) 1995-2016, Free Software Foundation, Inc.
Binding: hello.ali
No errors

$ gnatlink -v  hello

GNATLINK 6.4.0
Copyright (C) 1995-2016, Free Software Foundation, Inc.
gcc -c -mtune=generic -march=x86-64 -gnatA -gnatWb -gnatiw -gnatws 
/tmp/ada/b~hello.adb
/usr/bin/gcc.exe b~hello.o ./hello.o -o hello.exe -L./ 
-L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ -lgnat-6 
-Wl,--stack=0x200 -shared-libgcc


$ ./hello.exe
Hello WORLD!

$ cygcheck ./hello.exe |grep -v Windows
E:\cygwin64\tmp\ada\hello.exe
  E:\cygwin64\bin\cygwin1.dll
  E:\cygwin64\bin\cyggnat-6.dll
E:\cygwin64\bin\cyggcc_s-seh-1.dll

Thanks
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

[ANNOUNCEMENT] Updated: gcc-6.4.0-2 (x86/x86_64)

[JonY]

gcc-6.4.0-2 has been uploaded for Cygwin.

The missing import libraries for cyggnat-6 and cyggnarl-6 has been added.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



signature.asc
Description: OpenPGP digital signature

Updated: gcc-6.4.0-2 (x86/x86_64)

[JonY]

gcc-6.4.0-2 has been uploaded for Cygwin.

The missing import libraries for cyggnat-6 and cyggnarl-6 has been added.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



signature.asc
Description: OpenPGP digital signature

Re: cygwin Digest 2 Nov 2017 08:14:17 -0000 Issue 10515

[Stephen Lyons]

On 11/01/17 18:53, Chuck Wilde wrote on cygwin-digest-h...@cygwin.com:

> We did some debugging, and we eventually traced the problem down to using 
> Cygwin downloaded by use...@oncorems.com after 
> our userid was updated to use...@neotech.com.  
> Something must be cached somewhere, and the discrepancy between the domains 
> slows down commands tremendously.  We following the steps for Uninstalling 
> Cygwin from Windows, reinstalled it as 
> use...@neotech.com, and now our performance is 
> back to what it was before.
> 
> Chuck Wilde
> 408.914.8223
> NEOTech
> Naperville, IL USA
> 
> 
> “The recipient of this e-mail acknowledges and understands that certain 
> information contained in this email or in an attachment to this e-mail may be 
> subject to export controls and restrictions including, but not limited to, 
> the International Traffic in Arms Regulations (ITAR), the Export 
> Administration Regulations (EAR) or the sanctions administered by the Office 
> of Foreign Assets Control (OFAC). The recipient agrees not to disclose, 
> transfer, or otherwise export or re-export any technical data or other 
> Controlled information to any Foreign Person (including any foreign national, 
> foreign business or foreign government), whether in the United States or 
> abroad, without fully complying with U.S. export control regulations, 
> including obtaining any necessary license or other prior authorization 
> required from the appropriate agencies of the U.S. Government.”
> 

Um, what weird place does this poster live in - should they even *risk*
talk to everyone here? >8-) Do we *each* count as "the recipient" or is
it just the non-person that is the cygwin mailing list?  Given that the
footer is as big as the message I wish there was a meathod to decrease
the signal-to-noise ratio in some messages handled by the mail bot...!

Stephen

--
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: ada gnat import library missing ?

[JonY]

On 11/01/2017 04:07 PM, Marco Atzeri wrote:
> On 31/10/2017 00:17, JonY wrote:
> 
>> -2 with the appropriate import libraries should be coming along by the
>> end of the week if all goes well.
> 
> It is up but I see the same
> 
> $ ./hello.exe
>  -bash: ./hello.exe: cannot execute binary file: Exec format error
> 
> Does it work for you ?
> 

I think I solved the mystery, this generates a dll instead of an exe,
see the verbose output calling the compiler.





signature.asc
Description: OpenPGP digital signature

Re: Can I change the windows icon from command line?

[Andrey Repin]

Greetings, Thomas Wolff!

> I referred to changing the icon label (an existing sequence supported by
> xterm), i.e. the text shown in the taskbar, which cannot be changed in 
> Windows as far as I know as it's always the same as the window title.

Two thoughts on this:

1. The taskbar button title is not necessarily the same as [visible]
application window title.
One of the cleanest solutions is to create a frameless main window and embed
your actual application window inside it. Downside is that the visible
application window titlebar may not look right.
Another solution is to create two windows, one only shown in taskbar, one is
an actual app window, and repost all messages from taskbar to the application
window. Downside is that not all shell features may work properly, such as
minimize-restore on repeated clicks.
In support of this feature, I can say that I have restricted space for taskbar
labels myself (approx 10 symbols) and have to be creative with window titles
from various sources to clearly identify the windows.
That including dances with /etc/debian_chroot and manual PROMPT_COMMAND 
settings.

2. Since there's no direct solution for setting window icon, an existing
sequence could be reused for our purpose, since there's no clean way to make
it work straight. Or a new sequence could be invented.


-- 
With best regards,
Andrey Repin
Thursday, November 2, 2017 12:58:42

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: Solution to terrible performance in Cygwin under VPN

[Andrey Repin]

Greetings, Chuck Wilde!

> We did some debugging, and we eventually traced the problem down to using
> Cygwin downloaded by (domain)oncorems.com after our userid was updated
> to (domain)neotech.com.
> Something must be cached somewhere, and the discrepancy between the domains
> slows down commands tremendously.  We following the steps for Uninstalling
> Cygwin from Windows, reinstalled it as (domain)neotech.com, and now our
> performance is back to what it was before.

Another possible solution is to install and configure the cygserver[1].
It will aid in credentials caching from various domains as long as the
authority servers are accessible.

[1] https://cygwin.com/cygwin-ug-net/using-cygserver.html


-- 
With best regards,
Andrey Repin
Thursday, November 2, 2017 13:13:32

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

[ANNOUNCEMENT] Updated: weechat-1.9.1-2

[Sébastien Helleu]

Version 1.9.1-2 of "weechat" has been uploaded.

This version fixes a loading problem of Perl plugin.

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.

--
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: weechat-1.9.1-2

[Sébastien Helleu]

Version 1.9.1-2 of "weechat" has been uploaded.

This version fixes a loading problem of Perl plugin.

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.

Re: Can I change the windows icon from command line?

[Thomas Wolff]

Am 02.11.2017 um 03:39 schrieb Brian Inglis:

On 2017-11-01 15:10, Thomas Wolff wrote:

Am 01.11.2017 um 22:05 schrieb b...@theworld.com:

A trivial little shell script I use for setting xterm title/icon via escape
sequences:
...

That sequence is setting the icon *label*, not the icon. Mintty cannot support
it because there is no corresponding Windows function.

But there is a sequence of Windows functions from:

http://www.cplusplus.com/forum/general/28470/

summarizing (but this is from 2010 so may need tweaks):

"There are two icons in the window, 32x32 and 16x16.
If you want to change the the icon at the task bar and title bar you should do:

hIcon = (HICON)LoadImage(NULL, "menu_two.ico", IMAGE_ICON, 32, 32,
LR_LOADFROMFILE);
hIconSm = (HICON)LoadImage(NULL, "menu_two.ico", IMAGE_ICON, 16, 16,
LR_LOADFROMFILE);

LoadImage just loads the icon from the file. You need to assign the icon to the
window. You do this by sending a WM_SETICON message:

SendMessage( yourwnd, WM_SETICON, ICON_SMALL, (LPARAM)hIconSm );
SendMessage( yourwnd, WM_SETICON, ICON_BIG, (LPARAM)hIcon );

Reference: http://msdn.microsoft.com/en-us/library/ms632643(VS.85).aspx

I found out the difference with the ICON_SMALL and ICON_BIG, if you only set
ICON_SMALL then the Alt-Tab icon is stretched and looks bad.
If you set the ICON_BIG as well as ICON_SMALL, then everything looks nice."

For Xwindow icons, some approaches from google, depending on needs:

http://www.ideatrash.net/2014/10/howto-get-custom-icons-with-each-new.html
http://www.troubleshooters.com/linux/terminal_icon.htm
http://blog.samadamday.com/2014/automatically-set-windows-icons-based-on-gnome-theme/
https://superuser.com/questions/344320/how-do-i-change-the-icon-of-an-xterm
http://www.leonerd.org.uk/code/xseticon/

Thanks, Brian, for the links and the sample code which will make it easier.
This is about changing the icon, to get that sorted out.
I referred to changing the icon label (an existing sequence supported by 
xterm), i.e. the text shown in the taskbar, which cannot be changed in 
Windows as far as I know as it's always the same as the window title.

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