FS2020 can't deal with pathnames beyond 260 chars, problem and solutions

Brief description of the issue:

FS2020 is not handling physical path longer than 260 characters

See below for explanation and possible solutions.

Did you submit this to Zendesk? If so, what is your ticket #?

110064 FS2020 can’t deal with pathnames beyond 260 chars, problem and solutions

NB: I’ve been wondering about FS2020 and the way it is handling paths from some time and I’ve already posted most of the information below already, but recent news were compelling enough to raise this as a bug.

The problem

I thought this would have been corrected by now but the latest PMDG DC6 release notes are telling the problem is still there:

[03JUL21] PMDG DC-6 for MSFS Update to Build 2.00.0028 released via Operations Center - PMDG Simulations

In other words, you might end up moving your FS2020 folders in such a way that the complete path to an add-on file is so long that it exceeds the limit of 260 characters (known as MAX_PATH in Win32 SDK).

When the total file path name exceeds this limit, the file can’t be found nor read by FS2020 anymore because it exceeds the limits of the Virtual File System (VFS) physical file access capabilities.

Related problems


I’ve read reports of a problem where using a non ASCII character in the user account name is causing FS2020 to fail accessing the files properly, but this is supposed to be transparently handled when using the UCS2 Windows API like CreateFileW (instead of the equivalent ANSI Windows API like CreateFileA).

VFS Root too long

The standard path to the community folder is something like this:


This is already taking 151 characters out of the 260 available (MAX_PATH) and this doesn’t leave much remaining characters for any sub-folder.

The Question

It seems the FS2020 Virtual File System (VFS) is not capable of handling non-ANSI chars correctly when migrating add-ons from different systems configured with different locales and it is not able to access files which file paths are longer than 260 chars.

Both of these are making me wondering whether FS2020 is coded with the correct APIs and whether it is a bug, and I hope this information will help solving this.

Possible Solutions

1- The FS2020 VFS could support mounting .zip/7z archives in addition to simple folders

Mounting zip AND .7z files would not only solve the long filename problem but would also allow:

  • Huge savings of hard drive space.

  • Making it easier to “mod manage” all our add-ons in the community folder.

  • Huge saving in loading time because instead of issuing thousands of IOCTL, you’re only issuing 1 and you get the full directory and the file bits in one go.

In general, many VFS library are already supporting .zip (and some times others like 7z) natively. It is often a matter of just “enabling” mounting .zip archives in the VFS. If not, it is really not too complex though and .zip fits perfectly the typical VFS approach.

Why 7z though and not just .zip files?

I find it is in practice more efficient to compressing add-ons, most likely due to the efficiency on .DDS texture files.

2- The Windows API has functions for this:

Many file access functions also have a Unicode versions which permits extended-length path for a maximum total path length of 32,767 characters by using the extended-length path prefix:

Maximum Path Length Limitation - Win32 apps | Microsoft Docs

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

This seems to be simple a change to managing paths which I hope will prove helpful.

all these are n/a:

Do you have any add-ons in your Community folder? If yes, please remove and retest before posting.
Are you using Developer Mode or made changes in it?
Provide Screenshot(s)/video(s) of the issue encountered:
Detail steps to reproduce the issue encountered:
PC specs for those who want to assist (if not entered in your profile)
Build Version # when you first started experiencing this issue:
Are you on the Steam or Microsoft Store version?

How to enable file paths over 260 characters via Registry Editor (regedit)

Hit Start and type


Right-click Registry Editor and choose run as administrator

Navigate to the following key

HKEY_LOCAL_MACHINE → SYSTEM → CurrentControlSet → Control → FileSystem

Double-click a value named


Change the value from 0 to 1 and click ok.

Close Registry Editor and restart the computer.

How to enable file paths over 260 characters via Command Prompt (CMD)

Run the command prompt as administrator (CMD)

Hit Start and type CMD
Right-click command prompt and choose run as administrator


Copy the command below, paste into CMD.

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\FileSystem” /v LongPathsEnabled /t REG_DWORD /d 00000001 /f

press Enter

Close the command window and restart the computer.

How to enable file paths over 260 characters via Powershell

Run Powershell as administrator.

Hit Start and type Powershell
Right-click Windows PowerShell and choose run as administrator


Copy the command below, paste into PowerShell

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1

Press Enter

Close PowerShell window and restart the computer.

How to enable file paths over 260 characters via Local Group Policy Editor (gpedit.msc)

Hit Start and type


Right-click gpedit.msc and choose run as administrator

Navigate to

Local Computer Policy → Computer Configuration → Administrative Templates → System → Filesystem

Double click Enable Win32 long path and enable it.

Press Apply → Ok and and restart the computer.



I understand this might be one way to deal with these bugs and I thank you for sharing these, unfortunately the registry/gpedit workaround are working only with the UCS2 (‘W’) API (see notes at the end of the Microsoft document). In other words this won’t solve the fact this might not work should FS2020 is using many ANSI API. There seems a bug with accented characters is still there for some users and this most likely is related to the use of ANSI API too.

The official Microsoft document above is already describing both the registry and the gpedit information you’ve posted but I believe changing these system settings is no different in principle than asking a user to disable UAC to run a specific add-on. In other words, I don’t believe that asking an end user to alter his system settings using an admin command just for the sake of working around an application deficiency is the solution.

And in any case, this is a Microsoft application running on a Microsoft operating system which is already providing the necessary API and support at the application level in order to save non-admin end users from having to alter their system with admin commands, and I strongly believe this is a bug which needs to be corrected in the application only. The solution might prove to be as simple as adding the long path prefix in the VFS physical path name handling.


I’ve added this solution in the list, which I believe will not only solve the long filename problem easily at the OS file system level, but will also give much better performance (based on my experimentation with another simulator I won’t name).