Symlink issue?

[Ken Brown]

On 8/21/2021 4:15 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Hi,
> 
> Please consider the following Cygwin session:
> 
> $ cd ~
> $ pwd
> /home/user
> $ touch file
> $ ls file
> file
> $ cygpath -w ~
> C:\cygwin64\home\user
> $ mkdir /cygdrive/g/cygwin/dir
> $ ln -s /cygdrive/g/cygwin/dir ./dir
> $ ls -l dir
> ... dir -> /cygdrive/g/cygwin/dir/
> $ cd dir
> $ pwd
> /home/user/dir
> $ cygpath -w `pwd`
> G:\cygwin\dir
> $ ls -l ../fil<TAB>  (this expands to ../file but when Enter is hit):
> ls: cannot access '../file': No such file or directory
> 
> so basically "file" is not accessible with the relative dot-dot link,
> even though somehow readline (bash completion) can figure it out and suggest
> the correct completion.
> 
> Is this a Cygwin bug?

I don't think so.  I see identical behavior on Linux (using /tmp/dir instead of 
/cygdrive/g/cygwin/dir).

Pathname resolution proceeds from left to right, with symlinks expanded as they 
are encountered.  See "Pathname resolution" in

   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html

When the CWD is /home/user/dir, the resolution of ../file goes like this:

../file = /home/user/dir/../file
         = /cygdrive/g/cygwin/dir/../file
         = /cygdrive/g/cygwin/file,

which doesn't exist.

I don't know why bash completion suggests something different.  My guess (and 
it's only a guess) is that bash completion takes a shortcut for performance reasons.

Ken