realpath issue with native[strict] symlinks

[Jeremy Drake]

I apologize for not replying to the message properly, I am not subscribed
and am copy-pasting from web archive.

On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen wrote:
> The changes have a behavioral change, but I think this is for the
> better: Virtual drives are not treated as drives anymore, but as
> symlinks.  Given they are just pointers to other drives or directories,
> tha't much closer to reality.  I. e., in case of my above virtual drive
> T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is
> / only) is this:

I am concerned about this behavior.  The reason I was using subst to begin
with was that some build tools encode the full path in their filenames,
resulting in hitting MAX_PATH-related issues for not horribly long/deep
paths.  With this change, running a native Windows process (MinGW-w64)
from a subst drive results in what it sees as the CWD being 'dereferenced'
as though subst was not used, defeating the path-shortening purpose.

For instance, using your example mapping:
> $ ls -lG /cygdrive
> total 16
> d---r-x---+ 1 TrustedInstaller  0 Apr 29 21:07 c
> drwxr-xr-x  1 corinna           0 Dec 31  1979 e
> lrwxrwxrwx  1 corinna          32 May  6 20:43 t -> /cygdrive/c/cygwin64/home/corinna/tmp

Prior to these changes would show
$ cd /cygdrive/t && cmd /c cd
T:\

But after these changes would show
$ cd /cygdrive/t && cmd /c cd
C:\cygwin64\home\corinna\tmp

This path could well be long enough to trigger build issues for certain
MINGW-packages.

Sorry to be a nuisance...