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
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 4

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 4](https://forum.pmdg.com/forum/main-forum/general-discussion-
build-2-00-0028-released-via-operations-center) 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
CreateFile W (instead of the equivalent ANSI Windows API like CreateFile
A ).

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
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
using the extended-length path prefix : [Maximum Path Length Limitation -
Win32 apps | Microsoft Docs 2](https://docs.microsoft.com/en-

This type of path is composed of components separated by backslashes, each
up to the value returned in the lpMaximumComponentLength parameter of the
us/windows/desktop/api/FileAPI/nf-fileapi-getvolumeinformationa) 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. The solution might prove to be as simple as adding the long path
prefix in the VFS physical path name handling.

Just linking a post from another topic, in case this is relevant and in case
this helps with the above “idea”:

Hi Jean-Luc, We are already supposed to support long file paths (using the
right API calls and extended paths prefix) but maybe some sections of the code
are not actually going through the right classes/functions to handle them -
would you have a repro for this (like some sample that doesn’t work when
installed in path “XXX”)? Best regards, Eric / Asobo

Hi Eric, Thank you for looking into this. Searching the FS2020 forums with the
key words “character path” is still giving plenty of examples where people are
reaching the MAX_PATH limit even nowadays:
Or about non-ASCII
Like this one: <https://forums.flightsimulator.com/t/request-to-repair-
autopilot-is-not-performed-according-to-the-flight-plan/444918/7> Is this what
you’re looking for? Cordialement, Jean-Luc

addendum: I believe this bug is still tracked though?! [non-English Windows
User - Unable to start new flight, Permanent stuck on loading screen - Bug
Reports / Install, Performance & Graphics - Microsoft Flight Simulator
to-start-new-flight-permanent-stuck-on-loading-screen/367693) Do you think the
long path prefix also requires the registry hack to enable long path name by
default? (wouldn’t it defeat the purpose though ?!)
for-the-community-folder-can-you-please-resolve-this/386773/21?u=cptlucky8> Do
you think non-ASCII chars, despite using long path prefix and ‘W’ APIs also
requires enabling UTF8 support in the OS specifically? (wouldn’t it defeat the
purpose though ?!?) <https://forums.flightsimulator.com/t/cannot-start-the-