Re: misterious GIT failure (SOLVED)

Re: misterious GIT failure (SOLVED)

[matthew patton]

I excised the 2 symlink-involved PATH elements and now Git runs great with v3.1.5 of the DLL. I'll try one of the snapshots at some point, but I am also tempted to change my Bash function 'addPath()' to fully unroll symlinks before adding. https://github.com/tb3088/shell-environment/blob/master/.functions#L144    On Friday, January 15, 2021, 11:36:28 AM EST, matthew patton via Cygwin <cygwin@cygwin.com> wrote:  
 
 Ken Brown wrote:> Do you by any chance have symlinks in your PATH?
Yes, the first and 3rd entries are symlinks. I've had these symlinks in my PATH for years.
/home/MP1116/.aws/YYY/bin:/home/MP1116/bin -> .WPHOME/bin/

.aws -> .WPHOME/.aws/.WPHOME -> Dropbox/Work_Projects/XXX
#/etc/fstabC:/Users /home none binary,user 0 0

>  There was a problem reported in early December in which STATUS_IO_REPARSE_TAG_NOT_HANDLED > would sometimes occur when there was a symlink in PATH:

This KB was released 8 December. I installed it on Dec 23 and my git failures started after that date.https://support.microsoft.com/en-us/help/4592449/windows-10-update-kb4592449


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

Re: misterious GIT failure (SOLVED)

[Brian Inglis]

On Friday, January 15, 2021, 11:36:28 AM EST, matthew patton via Cygwin wrote:
> On 2021-01-15 10:09, matthew patton via Cygwin wrote:
>> Ken Brown wrote:
>>> Do you by any chance have symlinks in your PATH? There was a problem
>>> reported in early December in which STATUS_IO_REPARSE_TAG_NOT_HANDLED
>>> would sometimes occur when there was a symlink in PATH:

>> Yes, the first and 3rd entries are symlinks. I've had these symlinks in my 
>> PATH for years.
>> /home/MP1116/.aws/YYY/bin:/home/MP1116/bin -> .WPHOME/bin/
>> .aws -> .WPHOME/.aws/.WPHOME -> Dropbox/Work_Projects/XXX
>> # /etc/fstab
 >> C:/Users /home none binary,user 0 0

> I excised the 2 symlink-involved PATH elements and now Git runs great with 
> v3.1.5 of the DLL. I'll try one of the snapshots at some point, but I am also
> tempted to change my Bash function 'addPath()' to fully unroll symlinks
> before adding.
> https://github.com/tb3088/shell-environment/blob/master/.functions#L144
Resolving Cygwin paths is best done using readlink or realpath followed by 
cygpath -alm then cygpath -auU to get canonical paths, as neither realpath nor 
cygpath do the complete job under Cygwin.

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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: misterious GIT failure (SOLVED)

[Andrey Repin]

Greetings, Brian Inglis!

> On Friday, January 15, 2021, 11:36:28 AM EST, matthew patton via Cygwin wrote:
>> On 2021-01-15 10:09, matthew patton via Cygwin wrote:
>>> Ken Brown wrote:
>>>> Do you by any chance have symlinks in your PATH? There was a problem
>>>> reported in early December in which STATUS_IO_REPARSE_TAG_NOT_HANDLED
>>>> would sometimes occur when there was a symlink in PATH:

>>> Yes, the first and 3rd entries are symlinks. I've had these symlinks in my 
>>> PATH for years.
>>> /home/MP1116/.aws/YYY/bin:/home/MP1116/bin -> .WPHOME/bin/
>>> .aws -> .WPHOME/.aws/.WPHOME -> Dropbox/Work_Projects/XXX
>>> # /etc/fstab
 >>> C:/Users /home none binary,user 0 0

>> I excised the 2 symlink-involved PATH elements and now Git runs great with 
>> v3.1.5 of the DLL. I'll try one of the snapshots at some point, but I am also
>> tempted to change my Bash function 'addPath()' to fully unroll symlinks
>> before adding.
>> https://github.com/tb3088/shell-environment/blob/master/.functions#L144
> Resolving Cygwin paths is best done using readlink or realpath followed by 
> cygpath -alm then cygpath -auU to get canonical paths, as neither realpath nor
> cygpath do the complete job under Cygwin.

Can you provide examples? I find cygpath output satisfying so far, with
readlink if needs that bad.


-- 
With best regards,
Andrey Repin
Sunday, January 17, 2021 21:10:35

Sorry for my terrible english...

Re: misterious GIT failure (SOLVED)

[Brian Inglis]

On 2021-01-17 11:11, Andrey Repin wrote:
> Greetings, Brian Inglis!
>> On Friday, January 15, 2021, 11:36:28 AM EST, matthew patton via Cygwin wrote:
>>> On 2021-01-15 10:09, matthew patton via Cygwin wrote:
>>>> Ken Brown wrote:
>>>>> Do you by any chance have symlinks in your PATH? There was a problem
>>>>> reported in early December in which STATUS_IO_REPARSE_TAG_NOT_HANDLED
>>>>> would sometimes occur when there was a symlink in PATH:
> 
>>>> Yes, the first and 3rd entries are symlinks. I've had these symlinks in my
>>>> PATH for years.
>>>> /home/MP1116/.aws/YYY/bin:/home/MP1116/bin -> .WPHOME/bin/
>>>> .aws -> .WPHOME/.aws/.WPHOME -> Dropbox/Work_Projects/XXX
>>>> # /etc/fstab
>   >>> C:/Users /home none binary,user 0 0
> 
>>> I excised the 2 symlink-involved PATH elements and now Git runs great with
>>> v3.1.5 of the DLL. I'll try one of the snapshots at some point, but I am also
>>> tempted to change my Bash function 'addPath()' to fully unroll symlinks
>>> before adding.
>>> https://github.com/tb3088/shell-environment/blob/master/.functions#L144
>> Resolving Cygwin paths is best done using readlink or realpath followed by
>> cygpath -alm then cygpath -auU to get canonical paths, as neither realpath nor
>> cygpath do the complete job under Cygwin.
> 
> Can you provide examples? I find cygpath output satisfying so far, with
> readlink if needs that bad.

Sorry, it's been a few years now - there were a few issues testing various paths 
using various directories and links that neither readlink nor realpath resolved 
absolutely and correctly, so I added the cygpath to and fro to give a consistent 
path to support ordering and duplicate checking.

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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: misterious GIT failure (SOLVED)

[matthew patton]

On Sunday, January 17, 2021, 02:41:35 PM EST, Brian Inglis <brian.inglis@systematicsw.ab.ca> wrote:
 
 > Sorry, it's been a few years now - there were a few issues testing various paths > using various directories and links that neither readlink nor realpath resolved 
> absolutely and correctly, so I added the cygpath to and fro to give a consistent 
> path to support ordering and duplicate checking.


I haven't run into a scenario yet where 'readlink' doesn't work. But I also don't intermix Windows with my Cygwin except in rare occasion. What IS absolutely NUTS is Cygwin's treatment of spaces in PATH elements - it magically escapes them but refuses to recognize escaped spaces; considers them invalid. All other environment variables spaces have to be treated properly. 
Cygpath also blows up spectacularly when you feed '-w/-m' anything that isn't a syntactically perfect unix-style (colon delimited) character string.  

Re: misterious GIT failure (SOLVED)

[David Dyck]

On Sun, Jan 17, 2021 at 1:08 PM matthew patton via Cygwin <cygwin@cygwin.com>
wrote:

> I haven't run into a scenario yet where 'readlink' doesn't work. ....
>

Here's a unrelated example where symbolic links don't work the same as on
unix/linux ( not sure this is a readlink issue )

When I try to write through /proc to to a processes stdout I get errors
e.g.
$ ls -l /proc/1708/fd/1
lrwxrwxrwx 1 DavidD Domain Users 0 Jan 17 14:20 /proc/1708/fd/1 -> /dev/pty2

$ printf "\033]0;foo\7" > /proc/1708/fd/1
-bash: printf: write error: Bad file descriptor

but
$ printf "\033]0;foo\7" > /dev/pty2

works

I'm not sure if this is a readlink issue or just a bug in the cygwin
implementation of /proc :-)

Re: misterious GIT failure (SOLVED)

[Ken Brown]

On 1/15/2021 12:09 PM, matthew patton via Cygwin wrote:
> I excised the 2 symlink-involved PATH elements and now Git runs great with v3.1.5 of the DLL. I'll try one of the snapshots at some point,

You've almost certainly run into the same bug that was fixed in 
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=aec6479820fee5f71d50930bf0dde2bbf386bd4b, 
but it would be appreciated if you would confirm this by testing a snapshot.

Ken

Re: misterious GIT failure (SOLVED)

[matthew patton]

On Friday, January 15, 2021, 12:48:16 PM EST, Ken Brown via Cygwin <cygwin@cygwin.com> wrote:
 > but it would be appreciated if you would confirm this by testing a snapshot.
I have confirmed that running snapshot build Cygwin1.dll from 2021-01-13 handles symlinks in the PATH as expected.  

Re: misterious GIT failure (SOLVED)

[Ken Brown]

On 1/16/2021 12:22 PM, matthew patton wrote:
> On Friday, January 15, 2021, 12:48:16 PM EST, Ken Brown via Cygwin 
> <cygwin@cygwin.com> wrote:
>  > but it would be appreciated if you would confirm this by testing a snapshot.
> 
> I have confirmed that running snapshot build Cygwin1.dll from 2021-01-13 handles 
> symlinks in the PATH as expected.

Thanks for testing!

Ken