Re: realpath issue with native[strict] symlinks

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On May 14 21:12, Jeremy Drake via Cygwin wrote:
> 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.

Sorry, but there's only this or that, not both.  Either we revert the
entire change, including the native shortcut stuff, or we do it
completely and fully, including handling virtual drives as symlinks.

The alternative is to rewrite the path handling from scratch, which
is a massive undertaking I simply don't have the time for.

MAX_PATH is not of big concern anymore thiese days.  More recent Windows
10 allows long path names in the ANSI interface as well.  If you're using
dumb tools not being able to cope with such long paths, then use a wrapper
converting the affected paths back to a drive letter.

It might also be helpful to put matching functionality into the cygpath
tool.  Patches are welcome.


Corinna