Hi everybody,
This is sort of an issue.
Files with path around 300 will not open in sublime. This was reported back in 2013 : Cannot open file correctly when the path is too long for ST3 Build 3047
Now it is 2017 and it is still there in Build 3126.
I read that the 260 path length windows limitation was removed a while ago. I do not see why this issue was not fixed (even notepad++ can open long paths 
). It is a shame a free tool can do more than a tool I paid for.
Regards,
Gilberto
Try using Long Path Tool program that fixes issues of long path files with simplicity.
See this: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/
That’s not ST issue, that’s Windows limitation and it was removed only with the Anniversary Update of Windows 10.
Indeed
After adding the registry, ST3 was able to files with long paths.
Though, I wonder how the other tools were able to open them before I did the change…
Anyway, thanks @ihodev
I think that some other apps have hack for that, because I also had problems with long paths in the cmd.
To resolve these issues for currently Windows versions or windows servers is a software named “LONG PATH TOOL”, I suggest everyone a software “Long Path Tool“ which can solve all the long path problems.
I also use sublime text editor for my web projects. I must say its a great text editor. I love it. But the problem here is that it does not open long path name files. Actually no opeartions can be performed on such a file, and it becomes a mess after sometime when you can do anything about it. Just like a trojan or virus sitting on your system. To solve this I used GS Richcopy 360 which solved my problem. Till now In never encountered that problem again. Nice software to rely on.
I think that some other apps have hack for that, because I also had problems with long paths in the cmd.
There’s no hack, Windows NT simply supported different APIs since its creation. One compatible with legacy code and where path length is limited to ~260 characters and another Unicode-based one, where this limit didn’t apply. The problem is that paths need to be specially crafted to support the latter API and many somewhat bad tools didn’t learn to do this within the last decades. Sublime is one of those bad tools, but its support for different platforms isn’t very well at all anyway.
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the “\?” prefix. For example, "\?\D:\ very long path ".
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation
What has been introduced “lately” in Windows 10 is optionally removing the legacy compatibility limit to better support those somewhat bad tool which didn’t fully adopt to the Unicode-API yet.
We actually use the unicode versions of the Win32 API everywhere. For instance drag and drop for files works with longer paths, as do packages. We did have an issue with the open file dialog not working due to a missing manifest setting.
As can be clearly read in the provided docs, using the Unicode-APIs itself is only ONE part of support for long Unicode paths, apps additionally need to specially prefix paths with “\?”. This DOES NOT depend on any manifest settings at all. What does depend on manifest settings is the newly introduced “removal” of the MAX_PATH-restriction, which is a somewhat different topic.
Not being aware of that difference is a strong indication already that Sublime does not support long Unicode paths and everyone can easily test this on its own: This restriction doesn’t only apply in the file open-dialog, but using file searches etc. as well. I regularly hit that restriction and it’s one of the reasons I’m considering moving away from Sublime. If Sublime would use long Unicode paths, I simply wouldn’t hit that restriction.
And yes, I didn’t enable the “removal” of MAX_PATH yet, that’s not the point. The point is that this shouldn’t be necessary, because things would work OOB with default Windows-install already if Sublime would handle paths on Windows better.
Long paths do not require the \\?\ prefix to work, but we have fixed various issues with UNC paths for ST4. Note that this is with long paths disabled:
If you have any more specific issues with long paths please do add issues to our issue tracker with steps to replicate it and we’ll take a look at those.
Long paths do not require the
\\?\prefix to work[…]
Without that prefix, support for long paths NEEDS to be enabled in Windows 10 and the MS-docs are REALLY clear about that:
To enable the new long path behavior, both of the following conditions must be met:[…]
There are hundreds of other resources saying exactly the same and lots of other projects dealing with exactly the same issues in the same way. Not sure what you actually tested, but you might simply have a wrong impression:
The key’s value will be cached by the system[…]
Keep additionally in mind that Windows internally sometimes rewrites paths to use shorter 8.3-notation maintained in the background as well. Another reason why things might look like they succeed, while it’s actually not the desired behaviour.
Additionally, for some reason this concrete group policy doesn’t seem to have a default value. So once that setting has been enabled, if one puts it back to “not configured” afterwards, the enabled(!) value persists. One needs to explicitly choose “disabled”, which disables the option AND afterwards “not configured” keeps things disabled. So you most likely simply didn’t test what you expected to test.
Use something like “cmd.exe” instead, that can be closed and started with the group policy setting changed without the need to restart the whole system. You can easily test an enabled vs. disabled option using the following in a new cmd.exe:
cd C:\Users\tschoening\Downloads\sublime\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
That either succeeds or fails, depending on the group policy setting.
Looking at the manifest file of your Sublime-Exe, I don’t understand how this can even work at all, because your manifest simply lacks the additional necessary option:
<ws2:longPathAware>true</ws2:longPathAware>
vs. Sublime Text 3:
<asmv3:application>
<asmv3:windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/PM</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness>
</asmv3:windowsSettings>
</asmv3:application>
vs. cmd.exe:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
Therefore it makes totally sense that long paths don’t work properly for me, even after enabling the new setting. The following happens when opening a file in the formerly mentioned long directory:
Sublime wasn’t able to open the file properly and instead only recognized it existed, but couldn’t read its content.
The gif I showed was with the missing manifest setting applied. I’ve never enabled long paths on that machine, so even if the group policy display is wrong it should be defaulting to off.
Did you have a look at your registry? Search for “LongPathsEnabled” or have a look at the various different documented places.
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD)
You can’t really be arguing that the official MS-docs and the whole other world is wrong when saying that TWO requirements for that support are necessary, after you already proved that at least one part of what others tell is necessary for you as well. 
Besides that, how am I supposed to change the manifest of the Exe? Enabling the group policy simply doesn’t work for Sublime 3, while it does work for cmd.exe.
Besides that, how am I supposed to change the manifest of the Exe? Enabling the group policy simply doesn’t work for Sublime 3, while it does work for cmd.exe.
I don’t expect any users to change the manifest, I’m simply saying that we have a fix for ST4 pending. It does indeed look like something changed the registry entry, as I can’t replicate the behaviour on a fresher Windows install.
