Different symlink resolution in native console vs. terminal

Different symlink resolution in native console vs. terminal

[Andrey Repin]

Greetings, All!

Win 7 Pro fully upgraded.

Running `pwd -P` or `readlink -e .` in a specific directory from native
terminal provide unresolved answers.

The directory $HOME/Documents/EVE is a symlink pointing to $HOME\Documents\Games\EVE.

When running either command inside the directory from native terminal, the
result is literally /home/Documents/EVE, but when running the same command
from mintty inside same directory, the results may vary.

$HOME/Documents/EVE or $HOME/Documents/Games/EVE (which is expected answer).
It also seems, there are results difference between `bash -l` `and bash -i`
and `pwd -P` and `readlink -e .`.
Generally, "pwd" is more correct.


-- 
With best regards,
Andrey Repin
Thursday, March 11, 2021 1:33:36

Sorry for my terrible english...

Re: Different symlink resolution in native console vs. terminal

[L A Walsh]

On 2021/03/10 14:51, Andrey Repin wrote:
> Running `pwd -P` or `readlink -e .` in a specific directory from native
> terminal provide unresolved answers.
>
> The directory $HOME/Documents/EVE is a symlink pointing to $HOME\Documents\Games\EVE.
>
> When running either command inside the directory from native terminal, the
> result is literally /home/Documents/EVE, but when running the same command
> from mintty inside same directory, the results may vary.
>
> $HOME/Documents/EVE or $HOME/Documents/Games/EVE (which is expected answer).
> It also seems, there are results difference between `bash -l` `and bash -i`
> and `pwd -P` and `readlink -e .`.
> Generally, "pwd" is more correct.
>   
1) When you look at the processes(native v mintty), are both the
same #bits?

2) Can you reproduce this with any other dir?

Both Documents and Games have multiple copies due to the public
docs+games  are in the docs+games library (along with user versions).

Maybe the winterm is picking up a different file?

3) do you actually have a directory named '$HOME' or is it a real
dirname?

4) the symlink is in 'EVE' in both cases, yes?
Can you copy 'EVE' (the symlink) to a dir like /tmp and do they resolve
differently there?

I think one or both of those dirs have a GUID associated with them, maybe
one is using a different GUID than the other?

I also have Win7x64 but have never seen them misbehaving...

How was your link made?

Re: Different symlink resolution in native console vs. terminal

[Andrey Repin]

Greetings, L A Walsh!

> On 2021/03/10 14:51, Andrey Repin wrote:
>> Running `pwd -P` or `readlink -e .` in a specific directory from native
>> terminal provide unresolved answers.
>>
>> The directory $HOME/Documents/EVE is a symlink pointing to $HOME\Documents\Games\EVE.
>>
>> When running either command inside the directory from native terminal, the
>> result is literally /home/Documents/EVE, but when running the same command
>> from mintty inside same directory, the results may vary.
>>
>> $HOME/Documents/EVE or $HOME/Documents/Games/EVE (which is expected answer).
>> It also seems, there are results difference between `bash -l` `and bash -i`
>> and `pwd -P` and `readlink -e .`.
>> Generally, "pwd" is more correct.
>>   
> 1) When you look at the processes(native v mintty), are both the
> same #bits?

Interesting question. Originally I tested in 32-bit console, but it seems this
is not relevant.

$ START "" "%SystemRoot%\sysnative\cmd.exe"
$ CD /D "%USERPROFILE%\Documents\EVE"
$ readlink -e .
/home/anrdaemon/Documents/EVE

There's even MORE interesting sequence:

[anrdaemon@DAEMON2 C:\Users\anrdaemon\Documents\EVE]
$ bash -i
anrdaemon@daemon2:cygwin:~/Documents/EVE
$ readlink -e .
/home/anrdaemon/Documents/EVE
anrdaemon@daemon2:cygwin:~/Documents/EVE
$ cd "$( pwd )"
anrdaemon@daemon2:cygwin:~/Documents/EVE
$ readlink -e .
/home/anrdaemon/Documents/Games/EVE

> 2) Can you reproduce this with any other dir?

In fact. I picked a directory outside Cygwin mount table for this test:

[anrdaemon@DAEMON2 C:\]
$ MKLINK /J "C:\Games\KP2" "C:\Games\_old\KP2"
Junction created for C:\Games\KP2 <<===>> C:\Games\_old\KP2

[anrdaemon@DAEMON2 C:\Games]
$ CD /D "C:\Games\KP2"

[anrdaemon@DAEMON2 C:\Games\KP2]
$ pwd -P
/c/Games/KP2

[anrdaemon@DAEMON2 C:\Games\KP2]
$ readlink -e .
/c/Games/KP2

[anrdaemon@DAEMON2 C:\Games\KP2]
$ bash -i
anrdaemon@daemon2:cygwin:/c/Games/KP2
$ pwd -P
/c/Games/_old/KP2
anrdaemon@daemon2:cygwin:/c/Games/KP2
$ readlink -e .
/c/Games/KP2
anrdaemon@daemon2:cygwin:/c/Games/KP2
$ cd "$( pwd )"
anrdaemon@daemon2:cygwin:/c/Games/KP2
$ pwd -P
/c/Games/_old/KP2
anrdaemon@daemon2:cygwin:/c/Games/KP2
$ readlink -e .
/c/Games/_old/KP2

However, the C:\Games is a volume mount point. May be that is a problem?

Another test, this time no external factors, all directories in path are real:

[anrdaemon@DAEMON2 C:\]
$ MKLINK /J "C:\dev\php" "C:\dev\temp\install\php"

[anrdaemon@DAEMON2 C:\]
$ CD /D "C:\dev\php"

[anrdaemon@DAEMON2 C:\dev\php]
$ pwd -P
/c/dev/php

[anrdaemon@DAEMON2 C:\dev\php]
$ readlink -e .
/c/dev/php

> Both Documents and Games have multiple copies due to the public
> docs+games  are in the docs+games library (along with user versions).

As shown in the tests, this is not really a problem.

> Maybe the winterm is picking up a different file?

Eh? Terminal is just a display.

> I think one or both of those dirs have a GUID associated with them, maybe
> one is using a different GUID than the other?

???

> I also have Win7x64 but have never seen them misbehaving...

> How was your link made?

EVE is a symlink, but junctions behaving just the same and do not require
elevation to create.


-- 
With best regards,
Andrey Repin
Friday, March 19, 2021 15:49:11

Sorry for my terrible english...