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