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... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
