Does SourceTree fully support long Unicode paths under Windows?

Thorsten Schöning April 19, 2023

I'm currently using TortoiseGit and Git for Windows because I like the integration into Windows Explorer pretty much and has long time worked with TortoiseSVN already. Though, because being a Windows Explorer integration, under some circumstances TortoiseGit suffers from the max path length problem of Windows Explorer being 260 chars.

While Windows itself doesn't have that problem if long Unicode paths are used by an app, Windows Explorer has its own concept of paths and doesn't support this. This e.g. results in that Git for Windows supports a config "core.longpaths = true" and hence is able to e.g. recognize changes in files or revert files which some dialogs of TGIT itself can't handle. It then says something like it knows that a file was modified, because some native Git for Windows tells that, but can't access the file using Windows Explorer API to e.g. show DIFFs and stuff.


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".


So what about SourceTree, does that support long Unicode paths in Windows everywhere? And if so, does it support that by properly building paths as documented above or does one need to enable the newly introduced registry workaround?


Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.


Thanks for your input!

0 answers

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events