You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The change in 3.2.3 to ignore files in junctions and other forms of symlinks entirely did fix a mildly annoying issue when editing files behind them... at the expense of even more annoyingly breaking everything. It would be nice to get this actually fixed.
To Reproduce
Steps to reproduce the behavior:
Create a junction (mklink /J) inside a workspace.
Have a file reference meta data or other content inside that junction.
Expected behavior
Behave normally with symlinked files.
Additional commentary
Symlinks are a common thing, well-supported by every other piece of software I've written or encountered with little to no effort. I'm not really sure what the issue is here, and if it is on the extension's end or Visual Studio Code's. It does seem extension-specific though. In the modding scenes (where lua is popular), symlinks are also extremely common, to the point where its prevalence and native support in almost all games allows Nexus Mod's Vortex to use symlinks to generate modded game folders. I don't think the feature should be swept under the rug like this.
Environment:
OS: Windows
Is WSL remote? No.
Client: VSCode
The text was updated successfully, but these errors were encountered:
At present, I have encountered several problems, but I have no energy to solve them for the time being:
How to handle circular symlinks
How to handle symlinks points to a large directory
There is another premise: In windows, the case of the file name sent by VSCode may be different from the actual case, so I will retrieve the real file name, but this operation will penetrate the symlink.
We are also looking forward for the symlink support. Are there currently new plans regarding the symlinks?
Would it be otherwise possible (as a temporary solution) to add a configuration option which allows to switch between the behaviour of version 3.2.2 (and before) and version 3.2.3+? In this case, the user would be responsible for the directories they link, e. g., to avoid circular symlinks.
Just adding my voice in support of this. Not being able to use symlinks in my library is pretty debilitating. I have another project that I'm requiring files from, but the Factorio API requires a specific naming convention to access files from other mods. Right now, I have to manually copy the contents of that other mod into my library folder every so often, instead of it always being up-to-date.
Describe the bug
The change in 3.2.3 to ignore files in junctions and other forms of symlinks entirely did fix a mildly annoying issue when editing files behind them... at the expense of even more annoyingly breaking everything. It would be nice to get this actually fixed.
To Reproduce
Steps to reproduce the behavior:
mklink /J
) inside a workspace.Expected behavior
Behave normally with symlinked files.
Additional commentary
Symlinks are a common thing, well-supported by every other piece of software I've written or encountered with little to no effort. I'm not really sure what the issue is here, and if it is on the extension's end or Visual Studio Code's. It does seem extension-specific though. In the modding scenes (where lua is popular), symlinks are also extremely common, to the point where its prevalence and native support in almost all games allows Nexus Mod's Vortex to use symlinks to generate modded game folders. I don't think the feature should be swept under the rug like this.
Environment:
The text was updated successfully, but these errors were encountered: