Symlink issue?

Symlink issue?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

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'm using:
$ uname -a
CYGWIN_NT-6.1 XXXXX 3.2.0(0.340/5/3) 2021-03-29 08:42 x86_64 Cygwin

Cheers,

Anton Lavrentiev
Contractor NIH/NLM/NCBI

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

Re: Symlink issue?

[Thomas Wolff]

Am 21.08.2021 um 23:59 schrieb Ken Brown via Cygwin:
> 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.
The symlink/.. confusion is a dreadful trap since Unix times.
Unfortunately, bash completion does not consider path resolution, so if 
any, it's a bash completion bug.
Thomas
>
> Ken
>

Re: Symlink issue?

[Brian Inglis]

On 2021-08-21 18:40, Thomas Wolff wrote:
> 
> 
> Am 21.08.2021 um 23:59 schrieb Ken Brown via Cygwin:
>> 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.
> The symlink/.. confusion is a dreadful trap since Unix times.
> Unfortunately, bash completion does not consider path resolution, so if 
> any, it's a bash completion bug.

Try using cd -P (via alias?) which may resolve physically if it works.
Otherwise enjoy the quirks of cd via symlinks and .. resolution after.

-- 
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: Symlink issue?

[L A Walsh]

On 2021/08/21 17:55, Brian Inglis wrote:
> On 2021-08-21 18:40, Thomas Wolff wrote:
> >
> >
> > Am 21.08.2021 um 23:59 schrieb Ken Brown via Cygwin:
> >> On 8/21/2021 4:15 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin
> >> wrote:
> >>> Hi,
> >>> Please consider the following Cygwin session:
> >>> $ cd ~
> >> 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.
---
    cd w/completion uses the physical path because completion
is an external "script", while "cd" alone uses bash's internal
"logical" dir.
 
> > The symlink/.. confusion is a dreadful trap since Unix times.
> > Unfortunately, bash completion does not consider path resolution, so
> > if any, it's a bash completion bug.
---
    Not a bug or trap.  It is a user choice to have 'cd' use logical paths
instead of physical paths, whereas completion uses physical paths.

You can get physical paths w/cd with "set -P", but most people find
logical paths more friendly:

/tmp> ln -s .. foo
/tmp> cd foo            # really cd's into '/'
/tmp/foo> cd ..         # but logically '/tmp/foo'
/tmp> set -P            # turns on physical paths w/cd
/tmp> cd foo            # now cd 'foo' puts you in physical '/'
/> cd -                 # go back to last dir before 'cd'
/tmp> set +P            # turn off physical paths (logical back on)
/tmp> cd foo
/tmp/foo> cd ..
/tmp> rm foo

Or, as previously suggested.  One time usage w/param to 'cd'.
(Don't alias this, would be rather confusing)
>
> Try using cd -P (via alias?) which may resolve physically if it works.
> Otherwise enjoy the quirks of cd via symlinks and .. resolution after.

It's not just '..', but also when you 'cd' into a mounted
file system, then completion and other utils _may_
show you the contents of the dir the file system is mounted on.