Re: Git status delay

[Dawid Ferenczy]

Original   message  "Re: Git status delay"  from  "Adam Dinwoodie  
(a...@dinwoodie.org)" sent 21. listopadu 2017, 11:27:28,
msgid:20171121102728.gm20...@dinwoodie.org (3557 bytes):


> Your analysis is spot-on: Git is trying to find the directory that
> contains all the metadata for the current working copy, and traversing
> up the directory structure to do so.  In circumstances I haven't managed
> to characterise (I don't see this problem) it sometimes tries to parse
> //HEAD -- on most POSIX systems, this is equivalent to /HEAD, but on
> Cygwin it refers to the UNC path \\HEAD, which Windows attempts to look
> up on the network.  That network lookup is the cause of the delay you're
> seeing.

> (I believe this is a bug in Git, on the grounds that (a) Git in general
> supports POSIX systems and giving special meaning to paths starting with
> `\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
> supports Cygwin, and this is very well documented Cygwin behaviour.)


Hi,

   exactly!  I  can  confirm it. This is a screenshot from SysInternals' Process
   Monitor: https://ferenczy.cz/temp/cygwin-git-hang.png
   
   You  can  see  that  it  hanged  for about 30 seconds trying to open the file
   "\\HEAD\PIPE\wkssvc" which obviously failed with the BAD NETWORK PATH error. 
   On  my  system, it always hangs for the same amount time, it's most likely a 
   timeout.
   
   It  just  suddenly  started to happen (I have a Git status in my prompt so I 
   noticed it when my shell started to behave extremely slowly). I have tried 
to 
   update both Cygwin and Git and it didn't help.
   
   Also, it's happening even outside of any repository.
   
   I would also say it's more likely a Git's issue than Cygwin's.
 
-- 
S pozdravem,
 Dawid Ferenczy
 Senior web applications developer

 feren...@volny.cz
 http://ferenczy.cz
 http://twitter.com/DawidFerenczy

 PGP key ID: 0xA864A330EE1FE92B
___


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

Re: Cygport mailing list

[João Eiras]

Hi, is this list dead ?

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

Issue with resolving symlinks (realpath, readlink, etc)

[João Eiras]

Hi.

Programs and functions that rely in realpath() are broken.

Example:
$ cd
$ ln -s /var symlink
$ cd symlink
$ readlink -m .
/var
$ mkdir subfolder
$ cd subfolder
$ readlink -m .
/home/user/symlink/subfolder
# should be /var/subfolder

This is the block I think is causing problems, as it breaks the loop
as soon as a real file is found, instead of iterating further upwards
resolving ancestors.
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc#l994

There also a comment at line 736 that says:
"Scan path_copy from right to left looking either for a symlink or an
actual existing file. If an existing file is found, just return. If a
symlink is found, exit the for loop."

Thank 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

setup 2.883 release candidate - please test

[Jon Turney]

A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.883.x86.exe(32 bit version)
  https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version)

Please test and report problems to cygwin@cygwin.com. If no regressions 
are discovered in the next week or so, it will be promoted to release.


This is not the place for setup feature requests.

Changes compared to 2.882:

- Various improvements to behaviour after a download error
- Don't fatal() on unexpected early window messages
  (Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00428.html)
- Remove support for installing from a local directory which doesn't 
contain a setup.ini file
- Make 'System Proxy Settings' the default (for new installations) on 
the 'Select Connection Type' page, rather than 'Direct'
- Fix reading and writing of the "extrakeys" user setting. Maybe -U/-u 
does something useful now?
- Pressing enter in the URL textbox on the "Choose Download Site(s)" 
page now does 'Add', rather than 'Next'
- Pressing enter in the search textbox on the "Select Packages" page now 
causes the search to be performed, rather than 'Next'

- Fix concatenating depends: from each version description section
- Bullet-proof the way we remove empty categories
- If more than one download site is used, we now require downloading 
setup.ini from all of them to succeed, rather than just one of them.

- Various code rearrangements and simplifications

Thanks to Ken Brown for several of these changes.

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

Files created in cygwin on fileshare no longer allow "delete" in NTFS

[Eric Duesterhaus]

Hi Cygwin Community,

We are currently encountering an issue with Cygwin in regards to NTFS 
permissions on files created within Cygwin.  I'll try to outline my issue with 
specifics.

1.  There is a windows file server mapped to M:\ on the a windows computer 
running Cygwin.

2.  There is an active directory group that has "Modify" level permissions  on 
this file share (In NTFS, Modify includes explicit "delete" rights)

3.  "User1" and "User2" are both members of the aforementioned AD group.

4.  A file is created in /cygdrive/m/filepath/ through Cygwin being run as 
"User1".

5. "User2" attempts to delete this file.  It does not work (access denied).  

6. Upon further inspection of this file's ACL, the AD group with Modify level 
permissions now only has "read, write, execute" permissions, which, using 
windows "Effective Access" tool shows that the checkbox that assigns "delete" 
rights is no longer checked for this group.


I tried using getfacl on a file with the modify permission allowed to my AD 
group, then passed that file into setfacl with the -f option to overwrite the 
ACL of my created file.  From the NTFS point of view, my AD group still only 
has read/write/execute permissions instead of modify, which again, doesn't 
allow delete.

For information gathering I use the resultant file from getfacl to setacl -f on 
a file with "good" NTFS permissions, it overwrites the permissions and again, 
my AD group only has rwx and not "modify" permissions while looking at the ACL 
from windows.

How can I retain NTFS "delete" rights for my users and groups on files created 
by Cygwin?
 
Eric 


--
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: Git status delay

[Adam Dinwoodie]

On Monday 11 December 2017 at 02:37 pm +0100, Dawid Ferenczy wrote:
>You  can  see  that  it  hanged  for about 30 seconds trying to open the 
> file
>"\\HEAD\PIPE\wkssvc" which obviously failed with the BAD NETWORK PATH 
> error. 
>On  my  system, it always hangs for the same amount time, it's most likely 
> a 
>timeout.

Hi Dawid,

So I can look into this, I need the information I asked for in the email
you replied to.  To repeat, that's:

> - The cygcheck output per the bolded bullet in the problem reporting
>   guidelines: http://cygwin.com/problems.html.
> 
> - The version of Git you're running, per `git --version`, if it hasn't
>   been installed using Cygwin's setup-*.exe installers.
> 
> - The current working directory when you run `git status`.
> 
> - Details of the directory structure of the repository you're running
>   `git status` in.  I'm mainly after where the `.git` directory is in
>   relation to the current working directory, but if there's anything
>   else that's not entirely standard I'd like to know that, too (e.g. it
>   being a bare repository).
> 
> - Whether you're running Bash in MinTTY, Windows cmd shell, or something
>   else.
> 
> - If there's anything special about your shell prompt (e.g. you're using
>   one of the git prompt tools to include repository status summaries in
>   your shell prompt).

You've included some of that information in your reply, but I do need it
all to be able to look at this.

Also, per the mailing list notes at ,
please configure your mailer to not include people's email addresses in
your replies.

Cheers,

Adam

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

Re: Cygport mailing list

[Adam Dinwoodie]

On Monday 11 December 2017 at 05:48 pm +0100, João Eiras wrote:
> Hi, is this list dead ?

If by "this list" you mean cygwin@cygwin.com, no, it's definitely not
dead.  However the convention on this list is to only reply to the list,
not to individuals, so if you aren't subscribed to the list you won't
see the replies to your previous emails.

Marco Atzeri replied to your previous email on this thread; you can see
Marco's reply in the archives:

https://cygwin.com/ml/cygwin/2017-10/msg00329.html

Adam

--
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: Files created in cygwin on fileshare no longer allow "delete" in NTFS

[Jürgen Wagner]

Hi Eric,
  what are the permission settings on the containing directory?

Cheers,
--J.

On 11.12.2017 20:58, Eric Duesterhaus wrote:
> Hi Cygwin Community,
>
> We are currently encountering an issue with Cygwin in regards to NTFS 
> permissions on files created within Cygwin.  I'll try to outline my issue 
> with specifics.
>
> 1.  There is a windows file server mapped to M:\ on the a windows computer 
> running Cygwin.
>
> 2.  There is an active directory group that has "Modify" level permissions  
> on this file share (In NTFS, Modify includes explicit "delete" rights)
>
> 3.  "User1" and "User2" are both members of the aforementioned AD group.
>
> 4.  A file is created in /cygdrive/m/filepath/ through Cygwin being run as 
> "User1".
>
> 5. "User2" attempts to delete this file.  It does not work (access denied).  
>
> 6. Upon further inspection of this file's ACL, the AD group with Modify level 
> permissions now only has "read, write, execute" permissions, which, using 
> windows "Effective Access" tool shows that the checkbox that assigns "delete" 
> rights is no longer checked for this group.
>
>
> I tried using getfacl on a file with the modify permission allowed to my AD 
> group, then passed that file into setfacl with the -f option to overwrite the 
> ACL of my created file.  From the NTFS point of view, my AD group still only 
> has read/write/execute permissions instead of modify, which again, doesn't 
> allow delete.
>
> For information gathering I use the resultant file from getfacl to setacl -f 
> on a file with "good" NTFS permissions, it overwrites the permissions and 
> again, my AD group only has rwx and not "modify" permissions while looking at 
> the ACL from windows.
>
> How can I retain NTFS "delete" rights for my users and groups on files 
> created by Cygwin?
>  
> Eric 
>
>
> --
> 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
>
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Git status delay

[Richard H Lee]

On 21/11/2017 10:27, Adam Dinwoodie wrote:

(I believe this is a bug in Git, on the grounds that (a) Git in general
supports POSIX systems and giving special meaning to paths starting with
`\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
supports Cygwin, and this is very well documented Cygwin behaviour.)


I updated Cygwin and this problem has been fixed. Here's the upstream 
commit:

https://github.com/git/git/commit/57dd3dd28724a150e6c6d4c1c8363e1efd49c197.patch

What happened previously was that when is_git_directory("/") was called, 
git blindly appended "/HEAD" to the path, causing "//HEAD" (i.e. a 
network share) to be lstatted. The commit fixes this by only appending 
the '/' before "HEAD" only if it does not end in it already. Hence 
"/HEAD" is now lstatted as it should be.




In the name of being able to report this usefully upstream (and ideally
being able to reproduce it myself) can you give me a bit more
information about your environment?
I think the reason why so few people experienced this issue was that 
certain people have ISPs that use DNS hijacking. This is where 
non-existent DNS names are resolved to a catch-all IP address. They do 
this to monetise domain name typos. E.g. if someone mistypes the DNS 
part of the URL, the ISP's "not found" page will display adverts based 
upon terms extracted from the URL.


So if you lstat("//HEAD") and you are on a network that does DNS 
hijacking, Cygwin will attempt to connect to the ISP's server via SMB. 
As the ISP's server is a publicly facing IP address, it probably just 
black holes any incoming connection requests. So instead of receiving an 
immediate connection refusal, the TCP connection request just times out. 
This timeout was the cause of the delay.


--
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: Files created in cygwin on fileshare no longer allow "delete" in NTFS

[Eric Duesterhaus]

Hi Jürgen,

>From an NTFS standpoint, the containing directory allows "Modify" level access 
>to the AD group the users are members of.  Effective permissions shows the AD 
>group members can do the following to the containing folder by virtue of being 
>members of this group:

- Traverse folder / execute file
- List Folder /read data
- Read attributes
- Read extended attributes
- Create files /write data
- Create folders / append data
- Write attributes
- Write extended attributes
- Delete
- Read permissions

The following are NOT allowed of the AD group members:
- Full control
- Change Permissions
- Take ownwership

Any file placed in this directory through windows file management inherits the 
correct permissions.  Files created from within Cygwin, even if I just do a 
"touch filename" allow the AD group "Read, write & execute" access instead of 
"Modify" access.  In effective access, the following have check marks for users 
that are members of the AD group:

- Traverse folder / execute file
- List Folder /read data
- Read attributes
- Read extended attributes
- Create files /write data
- Create folders / append data
- Write attributes
- Write extended attributes
- Read permissions

Note that there are two differences:
1. Delete permission are now missing.
2. Inheritance has been disabled and all permissions that would have been 
inherited are on the file as explicit permissions, excepting "delete"

Thanks for the help so far!  Hopefully this answered your question.

> Hi Eric,
> what are the permission settings on the containing directory?
>
> Cheers,
> --J.

On 11.12.2017 20:58, Eric Duesterhaus wrote:
> Hi Cygwin Community,
>
> We are currently encountering an issue with Cygwin in regards to NTFS 
> permissions on files created within Cygwin.  I'll try to outline my issue 
> with specifics.
>
> 1.  There is a windows file server mapped to M:\ on the a windows computer 
> running Cygwin.
>
> 2.  There is an active directory group that has "Modify" level permissions  
> on this file share (In NTFS, Modify includes explicit "delete" rights)
>
> 3.  "User1" and "User2" are both members of the aforementioned AD group.
>
> 4.  A file is created in /cygdrive/m/filepath/ through Cygwin being run as 
> "User1".
>
> 5. "User2" attempts to delete this file.  It does not work (access denied).  
>
> 6. Upon further inspection of this file's ACL, the AD group with Modify level 
> permissions now only has "read, write, execute" permissions, which, using 
> windows "Effective Access" tool shows that the checkbox that assigns "delete" 
> rights is no longer checked for this group.
>
>
> I tried using getfacl on a file with the modify permission allowed to my AD 
> group, then passed that file into setfacl with the -f option to overwrite the 
> ACL of my created file.  From the NTFS point of view, my AD group still only 
> has read/write/execute permissions instead of modify, which again, doesn't 
> allow delete.
>
> For information gathering I use the resultant file from getfacl to setacl -f 
> on a file with "good" NTFS permissions, it overwrites the permissions and 
> again, my AD group only has rwx and not "modify" permissions while looking at 
> the ACL from windows.
>
> How can I retain NTFS "delete" rights for my users and groups on files 
> created by Cygwin?
>  
> Eric 
>
>
> --
> 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
>
>

 

-Original Message-
From: Eric Duesterhaus 
Sent: Monday, December 11, 2017 1:58 PM
To: 'cygwin@cygwin.com'
Subject: Files created in cygwin on fileshare no longer allow "delete" in NTFS 

Hi Cygwin Community,

We are currently encountering an issue with Cygwin in regards to NTFS 
permissions on files created within Cygwin.  I'll try to outline my issue with 
specifics.

1.  There is a windows file server mapped to M:\ on the a windows computer 
running Cygwin.

2.  There is an active directory group that has "Modify" level permissions  on 
this file share (In NTFS, Modify includes explicit "delete" rights)

3.  "User1" and "User2" are both members of the aforementioned AD group.

4.  A file is created in /cygdrive/m/filepath/ through Cygwin being run as 
"User1".

5. "User2" attempts to delete this file.  It does not work (access denied).  

6. Upon further inspection of this file's ACL, the AD group with Modify level 
permissions now only has "read, write, execute" permissions, which, using 
windows "Effective Access" tool shows that the checkbox that assigns "delete" 
rights is no longer checked for this group.


I tried using getfacl on a file with the modify permission allowed to my AD 
group, then passed that file into setfacl with the -f option to overwrite the 
ACL of my created file.  From the NTFS point of view, my AD group still only 
has read/write/execute permissions instead of modify, 

Re: Need help with multibyte UTF-8 characters

[Thomas Taylor]

Thank you for your advice on setting my locale to en_US.UTF-8.  
Unfortunately, Cygwin still seems to have trouble displaying some 
three-byte UTF-8 encoded characters correctly.  For example, see the 
following snippet from a "sed" file.  This file attempts to convert 
XML-encoded filenames to UTF-8.  As you can see, it converts one- and 
two-byte encodings correctly, but fails on some three-byte encodings 
(the en dash, the em dash, and the ellipsis, all of which are displayed 
as a filled-in rectangle):


# Match longest strings first

# Three-byte encodings:

# En dash
s/%[Ee]2%80%93/–/g

# Em dash
s/%[Ee]2%80%94/—/g

# Horizontal ellipsis
s/%[Ee]2%80%[Aa]6/…/g

# Less-than-or-equal sign
s/%[Ee]2%89%[Aa]4/≤/g

# Euro symbol
s/%[Ee]2%82%[Aa][Cc]/€/g

# Two-byte encodings:

# Non-break space
#s/%[Cc]2%[Aa]0/⎵/g

# Lowercase a with acute accent
s/%[Cc]3%[Aa]1/á/g

# Lowercase a with umlaut (a.k.a. diaeresis)
s/%[Cc]3%[Aa]4/ä/g

# Lowercase e with acute accent
s/%[Cc]3%[Aa]9/é/g

# Lowercase i with acute accent
s/%[Cc]3%[Aa]D/í/g

# Lowercase o with acute accent
s/%[Cc]3%[Bb]3/ó/g



--
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 2.883 release candidate - please test

[Steven Penny]

On Mon, 11 Dec 2017 18:46:30, Jon Turney wrote:

A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.883.x86.exe(32 bit version)
   https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version)

Please test and report problems to cygwin@cygwin.com. If no regressions 
are discovered in the next week or so, it will be promoted to release.


Here is an old issue - say you go to install a package, but your download is
corrupt. You get this:

   ---
   Cygwin Setup
   ---
   Package file wget has a corrupt local copy, please remove and retry.
   ---
   OK   
   ---


*Then setup closes*. This is not right. If the archive is missing, or if the
archive fails the SHA check, *then the file should be redownloaded by setup*,
and SHA check run again. With the current system, setup exits, then the user has
to navigate to where the problem file is, for example:

C:\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\wget

then delete the problem file, then restart setup. I cant see why setup shouldnt
just automate all of this. Also here is a new issue - on the "Select Connection
Type" page - "Use System Proxy Settings" is the first choice, and by default the
selected choice. "Direct Connection" should be the first choice, and by default
the selected choice.


--
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: Files created in cygwin on fileshare no longer allow "delete" in NTFS

[Larry Hall (Cygwin)]

On 12/11/2017 05:19 PM, Eric Duesterhaus wrote:

How can I retain NTFS "delete" rights for my users and groups on
files created by Cygwin?





Note that there are two differences:
1. Delete permission are now missing.
2. Inheritance has been disabled and all permissions that would have
been  inherited are on the file as explicit permissions, excepting "delete"


You haven't said yet how the M drive is mounted as far as Cygwin is
concerned.  Is it using Cygwin ACLs or not?  It looks to me like it is.
But if that doesn't explain what you're seeing, I would recommend using the
guidelines below with any follow-up to the list so we have some baseline
information and can eliminate anything obvious.


Problem reports:   http://cygwin.com/problems.html

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

libnet on cygwin: how to deal with libpcap?

[Gianpaolo Pedrazza]

Dear all,
I need to install libnet and I found on various sites [2][3] that the
only one way to install the prerequisite libpcap is to extract the
Developer Pack [4] into cygwin. I did it, I run all the tests and the
pcap library seemed to work pretty well. So I run the configure file
the latest available version of libnet and I was able to create the
Makefile. My problem comes running the "make" command, because the
libpcap library includes winsock2.h while libnet is based on socket.h.
Is this definitely an incompatibility between the two libraries or
there is something which can be done? Does someone know another way to
install libpcap on cygwin?

Cheers,
Gianpaolo


[1] https://sourceforge.net/projects/libnet-dev/
[2] https://www.unix.com/unix-for-beginners-questions-and-answers/26518
0-installing-winpcap-configure-cygwin.html
[3] https://stackoverflow.com/questions/2396251/help-installing-libpcap
-on-cygwin
[4] https://www.winpcap.org/devel.htm

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