Re: Fonts reorganization and additions

[Ken Brown]

On 9/13/2015 12:10 PM, Ken Brown wrote:

On 9/11/2015 3:59 PM, Yaakov Selkowitz wrote:

The first thing that should be checked is if the code in setup which
allows it to unpack files with "illegal" characters in Windows also
makes sure to create parent directories.  Based on these reports my
*guess* is it doesn't but I haven't looked yet.


I'm not very familiar with the setup code, but I think I may have found
the problem.  The function mkdir_p() in mkdir.cc contains the following,
starting at line 99:

   for (c = path; *c; c++)
 {
   if (*c == ':')
 slash = 0;
   if (*c == '/' || *c == '\\')
 slash = c;
 }

   if (!slash)
 return 0;

If I understand this correctly, the function will return success without
having created the leading directory if the path name contains a colon
and doesn't contain a slash after the last colon.  I guess the
assumption is that there is no "leading directory" to be created in this
case.  [This part of the code was written in 2000, when a colon could
not be part of a file name.]

I hope someone who understands the setup code better than I do can take
a look at this.  I'm not confident that I understand all the uses of
mkdir_p() or all possible reasons why its in_path argument might contain
a colon.


The following patch fixes the problem:

diff --git a/mkdir.cc b/mkdir.cc
index dabc256..84bb176 100644
--- a/mkdir.cc
+++ b/mkdir.cc
@@ -98,8 +98,6 @@ mkdir_p (int isadir, const char *in_path, mode_t mode)

   for (c = path; *c; c++)
 {
-  if (*c == ':')
-   slash = 0;
   if (*c == '/' || *c == '\\')
slash = c;
 }

I don't know if this might cause some other problem, but it seems OK in 
limited testing.


Ken


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

Re: Error accessing mapped drive >2TB?

[Warren Young]

On Sep 12, 2015, at 11:14 AM, Nem W Schlecht  wrote:
> 
> The only thing I can think of is that the 2nd drive is >2TB.

The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external 
drive, so no, I don’t think the volume size is the real issue.

I assume you are seeing the same thing that I am, that Explorer shows the root 
contents of both drives just fine?

When I strace’d an ls of one of these root shares here, I got 764 lines 
of…emissions, of which this section seems the most interesting to me:

1051  263166 [main] ls 4720 stat64: entering
  625  263791 [main] ls 4720 normalize_posix_path: src /p
  609  264400 [main] ls 4720 normalize_posix_path: /p = normalize_posix_path 
(/p)
  630  265030 [main] ls 4720 mount_info::conv_to_win32_path: conv_to_win32_path 
(/p)
  653  265683 [main] ls 4720 mount_info::cygdrive_win32_path: src '/p', dst 
'P:\'
  668  266351 [main] ls 4720 set_flags: flags: binary (0x2)
  674  267025 [main] ls 4720 mount_info::conv_to_win32_path: src_path /p, dst 
P:\, flags 0x4022, rc 0
 1168  268193 [main] ls 4720 symlink_info::check: 0x0 = NtCreateFile (\??\P:\)
10641  278834 [main] ls 4720 symlink_info::check_reparse_point: 
NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, 0xC275
  839  279673 [main] ls 4720 symlink_info::check: not a symlink
 1049  280722 [main] ls 4720 symlink_info::check: 0 = symlink.check(P:\, 
0x24B620) (0x4022)
  655  281377 [main] ls 4720 path_conv::check: this->path(P:\), has_acls(0)
  640  282017 [main] ls 4720 stat_worker: got 5 error from path_conv
  757  282774 [main] ls 4720 __set_errno: int stat_worker(path_conv&, 
stat*):1933 setting errno 5
  714  283488 [main] ls 4720 stat_worker: -1 = (\??\P:\,0x600042080)

Why errno 5 from path_conv?

Yes, I am one of those evil people who edit cygdrive out of /etc/fstab so I can 
use /x, where x=drive letter. :)
--
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: git-review-1.25.0-1

[David Rothenberger]

git-review has been updated to 1.25.0.

DESCRIPTION:

git-review is a tool that helps submitting git branches to gerrit
for review.

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

-- 
David Rothenberger    daver...@acm.org

[ANNOUNCEMENT] Updated: git-review-1.25.0-1

[David Rothenberger]

git-review has been updated to 1.25.0.

DESCRIPTION:

git-review is a tool that helps submitting git branches to gerrit
for review.

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

-- 
David Rothenberger    daver...@acm.org

--
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: Fonts reorganization and additions

[Ken Brown]

On 9/14/2015 1:40 PM, Ken Brown wrote:

On 9/13/2015 12:10 PM, Ken Brown wrote:
The following patch fixes the problem:

diff --git a/mkdir.cc b/mkdir.cc
index dabc256..84bb176 100644
--- a/mkdir.cc
+++ b/mkdir.cc
@@ -98,8 +98,6 @@ mkdir_p (int isadir, const char *in_path, mode_t mode)

for (c = path; *c; c++)
  {
-  if (*c == ':')
-   slash = 0;
if (*c == '/' || *c == '\\')
 slash = c;
  }

I don't know if this might cause some other problem, but it seems OK in
limited testing.


If anyone else wants to test this, my builds are at

  http://sanibeltranquility.com/cygwin/setup-2.871-1-g0ef99d.tar.xz

This is based on the sources for setup 2.871, with the above patch applied.

Ken



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

Re: Error accessing mapped drive >2TB?

[Andrey Repin]

Greetings, Warren Young!

>> The only thing I can think of is that the 2nd drive is >2TB.

> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB
> external drive, so no, I don’t think the volume size is the real issue.

> I assume you are seeing the same thing that I am, that Explorer shows the
> root contents of both drives just fine?

> When I strace’d an ls of one of these root shares here, I got 764 lines
> of…emissions, of which this section seems the most interesting to me:

> 1051  263166 [main] ls 4720 stat64: entering
>   625  263791 [main] ls 4720 normalize_posix_path: src /p
>   609  264400 [main] ls 4720 normalize_posix_path: /p = normalize_posix_path 
> (/p)
>   630  265030 [main] ls 4720 mount_info::conv_to_win32_path: 
> conv_to_win32_path (/p)
>   653  265683 [main] ls 4720 mount_info::cygdrive_win32_path: src '/p', dst 
> 'P:\'
>   668  266351 [main] ls 4720 set_flags: flags: binary (0x2)
>   674  267025 [main] ls 4720 mount_info::conv_to_win32_path: src_path /p, dst 
> P:\, flags 0x4022, rc 0
>  1168  268193 [main] ls 4720 symlink_info::check: 0x0 = NtCreateFile (\??\P:\)
> 10641  278834 [main] ls 4720 symlink_info::check_reparse_point:
> NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, 0xC275
>   839  279673 [main] ls 4720 symlink_info::check: not a symlink
>  1049  280722 [main] ls 4720 symlink_info::check: 0 = symlink.check(P:\, 
> 0x24B620) (0x4022)
>   655  281377 [main] ls 4720 path_conv::check: this->path(P:\), has_acls(0)
>   640  282017 [main] ls 4720 stat_worker: got 5 error from path_conv
>   757  282774 [main] ls 4720 __set_errno: int stat_worker(path_conv&, 
> stat*):1933 setting errno 5
>   714  283488 [main] ls 4720 stat_worker: -1 = (\??\P:\,0x600042080)

> Why errno 5 from path_conv?

> Yes, I am one of those evil people who edit cygdrive out of /etc/fstab so I 
> can use /x, where x=drive letter. :)

That's an interesting point... can you walk me through your setup, so I could
try to recreate the issue?
Or is this Mac-specific?


-- 
With best regards,
Andrey Repin
Tuesday, September 15, 2015 06:45:22

Sorry for my terrible english...

Re: Cygwin terminal weirdness

[Andrey Repin]

Greetings, cyg Simple!

>> This is best explained with a video ( apparently, list don't like videos ),
>> but for a quick reference, here's a description of observed behavior:
>> 

> It might accept a link to an external service, maybe.

It doesn't.


-- 
With best regards,
Andrey Repin
Tuesday, September 15, 2015 06:54:46

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: HTTPS - Error setting certificate verify locations

[Tae Lim Kook]

Hello, Andrey,

> Ok, I did some more digging and the location your curl refers to is also 
> appears to be correct. (Although it is heavily cross-symlinked and hard to 
> track.)
> Make sure you have only one Cygwin install and/or that you're updating the 
> right one.

Yes, indeed I have only one Cygwin install.
However, since autorebase.dash hangs at the end of setup.exe, I close
it when it reaches that process. Perhaps this might contribute to the
problem?

Sincerely,

Tae Lim Kook

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

[Andrey Repin]

Greetings, Warren Young!

>> Call "man" on a sufficiently long topic. man bash would be quite sufficient.
>> Or just `less` a long enough text.
>> Hold down "End" key.
>> The screen buffer will jump and tear repeatedly, until you release the key.

> That sounds like a video card performance issue, not a Cygwin, mintty, or 
> less issue.

I can't believe it is a gfx performance issue, as I can't reproduce it with
PuTTY in the same situation.
I.e.
native console/local less = jumping and tearing.
mintty/local less = jumping and tearing.
native console/ssh+less = jumping and tearing.
mintty/ssh+less = jumping and tearing.
putty+less = no jumping, no tearing.

Let's try a different approach. The video id is ne3VmLZmD9g on a well-known
tube hosting service.

> I just tried it here on a VM hosted on a box with an NVIDIA GeForce GTX
> 680MX GPU, and all I saw was normal redrawing, with scarcely any tearing. 
> That chip is about 3 years old, which probably still outperforms any current 
> CPU-integrated GPU.

> There are some small mitigations that might help.

> One would be to convince the maintainers of less to be smarter about
> repainting the whole screen when it isn’t necessary.  But given that they
> haven’t fixed the horizontal scrolling bug in the ~20 years I’ve been using
> it, I wouldn’t hold out hope on that front.

Well, let's say, this is unconvincing.

> Another would be to make mintty double-buffer its screen, if it doesn’t
> already.  That won’t help with the clear-screen call less is currently
> making, but it might reduce the tearing effect.

> The same thing is happening with something like “ls -lR /“.  The only
> difference is that you can easily see what’s going on in the “man bash”
> case, since the content remains static.

> Another way to see it is “vim /etc/sshd_config”, then hold down Ctrl-L.

I'm not familiar with vi/m, so I'll just trust you on the matter.


-- 
With best regards,
Andrey Repin
Tuesday, September 15, 2015 06:47:19

Sorry for my terrible english...

Re: HTTPS - Error setting certificate verify locations

[Andrey Repin]

Greetings, Tae Lim Kook!

http://cygwin.com/acronyms/#TOFU pretty please.

>>> I'm getting an error every time I try to get content with HTTPS (e. g.
>>> curl, wget, git).
>>
>>> $ curl https://google.com
>>> curl: (77) error setting certificate verify locations:
>>>   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>>>   CApath: none
>>
>>> I have read that this problem can be solved by installing
>>> ca-certificates, but the error persists even when version 2.5-1 is
>>> installed.
>>
>> You seems to have altered curl config.
>> ca-certificates are installed into (de facto) standard location in 
>> /etc/ssl/certs
>> curl by default search for them there.
>> Check your ~/.curlrc for any stray overrides.

> That file does not exist on my system.

Ok, I did some more digging and the location your curl refers to is also
appears to be correct. (Although it is heavily cross-symlinked and hard to
track.)
Make sure you have only one Cygwin install and/or that you're updating the
right one.


-- 
With best regards,
Andrey Repin
Tuesday, September 15, 2015 06:56: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

Re: Cygwin terminal weirdness

[cyg Simple]

On 9/13/2015 2:36 PM, Andrey Repin wrote:
> Greetings, All!
> 
> This is best explained with a video ( apparently, list don't like videos ),
> but for a quick reference, here's a description of observed behavior:
> 

It might accept a link to an external service, maybe.

> Call "man" on a sufficiently long topic. man bash would be quite sufficient.
> Or just `less` a long enough text.
> Hold down "End" key.
> The screen buffer will jump and tear repeatedly, until you release the key.
> Doesn't matter, if you exercise it in mintty or native console, it is all the
> same.

Patient: Doctor, doctor my eye hurts sometimes.
 Doctor: When does it hurt?
Patient: When I put my finger in my eye it hurts!
 Doctor: My advice to you is to stop putting your finger in your eye.

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

[Warren Young]

On Sep 13, 2015, at 12:36 PM, Andrey Repin  wrote:
> 
> Call "man" on a sufficiently long topic. man bash would be quite sufficient.
> Or just `less` a long enough text.
> Hold down "End" key.
> The screen buffer will jump and tear repeatedly, until you release the key.

That sounds like a video card performance issue, not a Cygwin, mintty, or less 
issue.

I just tried it here on a VM hosted on a box with an NVIDIA GeForce GTX 680MX 
GPU, and all I saw was normal redrawing, with scarcely any tearing.  That chip 
is about 3 years old, which probably still outperforms any current 
CPU-integrated GPU.

There are some small mitigations that might help.

One would be to convince the maintainers of less to be smarter about repainting 
the whole screen when it isn’t necessary.  But given that they haven’t fixed 
the horizontal scrolling bug in the ~20 years I’ve been using it, I wouldn’t 
hold out hope on that front.

Another would be to make mintty double-buffer its screen, if it doesn’t 
already.  That won’t help with the clear-screen call less is currently making, 
but it might reduce the tearing effect.

The same thing is happening with something like “ls -lR /“.  The only 
difference is that you can easily see what’s going on in the “man bash” case, 
since the content remains static.

Another way to see it is “vim /etc/sshd_config”, then hold down Ctrl-L.
--
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: NOACL leads to a massive speed slowdown in file system processes

[Andrey Repin]

Greetings, tiwa...@arcor.de!

I would really appreciate, if you teach your mail agent to insert proper
threading headers.
Thank you in advance.

>> This is not the default exactly because of its nature.
>> It is unusable. You will not be able to run scripts from such mount point.

> No problem for me, I have my scripts in my cygwin home/bin. Why put them
> outside? That's their environment.

Because my $HOME on noacl mount. In fact it is matching my %USERPROFILE%.

>> However, I don't quite understand the nature of the issue here. Why not 
>> assume
>> all files "executable", and only check the magic word, when we actually 
>> trying
>> to execute them?

> True.
> Or all normal files like exe, com, bat, sh as executable, and the other
> ones manually with chmod. That information could be saved in a sqlite DB. 
> Just an idea ;)

I would say, "just trust ACLs".
The cases of filesystem not supporting any ACL whatsoever being used with
Cygwin are very rare nowadays.


-- 
With best regards,
Andrey Repin
Monday, September 14, 2015 21:40:03

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: HTTPS - Error setting certificate verify locations

[Andrey Repin]

Greetings, Tae Lim Kook!

> Hello!

> I'm getting an error every time I try to get content with HTTPS (e. g.
> curl, wget, git).

> $ curl https://google.com
> curl: (77) error setting certificate verify locations:
>   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>   CApath: none

> I have read that this problem can be solved by installing
> ca-certificates, but the error persists even when version 2.5-1 is
> installed.

You seems to have altered curl config.
ca-certificates are installed into (de facto) standard location in 
/etc/ssl/certs
curl by default search for them there.
Check your ~/.curlrc for any stray overrides.


-- 
With best regards,
Andrey Repin
Monday, September 14, 2015 21:32:26

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: HTTPS - Error setting certificate verify locations

[Tae Lim Kook]

That file does not exist on my system.

On Mon, Sep 14, 2015 at 2:39 PM, Andrey Repin  wrote:
> Greetings, Tae Lim Kook!
>
>> Hello!
>
>> I'm getting an error every time I try to get content with HTTPS (e. g.
>> curl, wget, git).
>
>> $ curl https://google.com
>> curl: (77) error setting certificate verify locations:
>>   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>>   CApath: none
>
>> I have read that this problem can be solved by installing
>> ca-certificates, but the error persists even when version 2.5-1 is
>> installed.
>
> You seems to have altered curl config.
> ca-certificates are installed into (de facto) standard location in 
> /etc/ssl/certs
> curl by default search for them there.
> Check your ~/.curlrc for any stray overrides.
>
>
> --
> With best regards,
> Andrey Repin
> Monday, September 14, 2015 21:32:26
>
> 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: NOACL leads to a massive speed slowdown in file system processes

[tiwasey]

> This is not the default exactly because of its nature.
> It is unusable. You will not be able to run scripts from such mount point.

No problem for me, I have my scripts in my cygwin home/bin. Why put them 
outside? That's their environment.

> However, I don't quite understand the nature of the issue here. Why not assume
> all files "executable", and only check the magic word, when we actually trying
> to execute them?

True.
Or all normal files like exe, com, bat, sh as executable, and the other ones 
manually with chmod. That information could be saved in a sqlite DB. Just an 
idea ;)

--
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: mintty hangs after exit

[Thomas Wolff]

Sorry for some delay in responding to this again:

Am 22.08.2015 um 19:03 schrieb Andrey Repin:

Greetings, Thomas Wolff!


Am 22.08.2015 um 06:31 schrieb Sam Edge:

On 22/08/2015 05:05, John Hein wrote:

Andrey Repin wrote at 02:05 +0300 on Aug 22, 2015:
   > Just noticed a weird thing. Wonder if anyone can confirm or deny the issue.
   >
   > 1. Start mintty as `mintty.exe -` (i.e. login shell)
   > 2. Execute a command. S.a. "ssh anywhere"
   > 3. Exit all running apps. I.e. ^D out of all shells.
   > 4. mintty remains running.
   > There's no more child processes of it, nothing. It's just stuck around.

...

...
And yes, it seems to only happen with OpenSSH.
And pressing Enter in a stalled mintty window forces it to close.

I can reproduce this with the mintty option -h error or -o Hold=error
which I guess you have configured in .minttyrc.
Mintty does not terminate then if its child (usually the shell)
terminates with an error exit condition; in recent versions, it will
show a red notice about this.
You can easily try it by typing ^C in bash, then ^D, and mintty (with
hold error) will stay.
If you run ssh, and an error occurs in ssh (e.g. type ^C there as its
last action), that is apparently propagated back to the local shell.
Thomas

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