Continuing the discussion from Mp3tag Development Build Status:
Could you please explain this change in behavior in detail?
Consider a symbolic link (created via mklink /D)
C:\Music\Link pointing to \\server\share\music\
Before v3.30c, Mp3tag was dereferencing symbol links when navigating via symbolic links that point to folders. So if you chose File → Change directory... and enter C:\Music\Link\, the location was automatically changed to \\server\share\music\. Same with export file names and more.
Contrary to that, if you chose File → Change directory... and pointed to C:\Music\, the files under C:\Music\Link\ were listed as such (not \\server\share\music\) in Mp3tag.
Furthermore, Windows Explorer preserves the link location when navigating into C:\Music\Link\.
With the change in v3.30c, I'm trying to preserve the user intent of using symbolic links as a means of abstraction from the actual location. In addition, I try to be more in line with platform conveniention, i.e., the behaviour of, e.g., Windows Explorer.
This is why C:\Music\Link\ is now preserved, also when navigating into the linked folder.
Thanks for this change. It was always a little confusing but I arranged myself to this behavior. From now on I have to remember that the path I see in the columns is the path to the link-directory and not to the directory the files reside in.
Yes, it was partly like that before this change: if the linked folder was inside the loaded folder, it would also have displayed the path to the link directory.