ArchiverFS - Long Path Suport

Home | Product Home | Pricing | Download | Documentation | Release Notes | Customers

Long path support & the Windows OS

We have all been there at one point or another.. "The path is longer than the Windows supported maximum path length", "The path is too long for the recycle bin" or maybe if you are a developer it's a 'System.IO.PathTooLong' Exception. It's an error message most people have come across in one form of another.

There are lots of great resources that explain why Windows has had this limit on path lengths of between 253 and 260 characters (varies by OS and situation), but we are going to look at what it means to your average user today and how it affects the operation of ArchiverFS.

Windows 10, Server 2016 and Server 2019 all include OS level support for long paths. This is a big step forward from Microsoft and definitely a move in the right direction, by adding a single registry key (or setting a group policy) you can instantly enable support for paths thousands of characters long. The steps to turn on support for long paths are about as simple as it gets:

Group Policy

1. Open Group Policy Editor.
2. Find the following section: Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem.
3. Edit the setting called 'Enable Win32 Long Path' and enable it.
4. Once your Group Policies have been pushed out to your machines OS level long path support will be enabled. The setting takes effect without a reboot being needed.

Registry

1. Open Regedit and navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\FileSystem.
2. Create a new DWORD value named 'LongPathsEnabled' if it doesn't already exist.
3. Set the value to ‘1’.
4. The setting takes effect without a reboot being needed.

So that's it then, just enable long path support on all your workstations and servers and you never need worry about long paths again? Well... not quite...

Even though the addition of OS level support for long paths is welcome, it is completely useless for the vast majority of users. You see, long path support has to be enabled at both the OS and application level.

Not only do you need to enable support at the OS level as above, but the developers of the application you are using also have to explicitly declare that their application supports long paths. This is done in the application manifest file and has to be done by the application developers. The application manifest is embedded within the .exe file for each application and it is out of reach unless you have the source code for the application and are compiling the .exe yourself. The setting to add to an application manifest looks like this:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
        <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
    </windowsSettings>
</application> 

Unless you are the application developer you can't edit that setting. On top of this, if you are working with a .Net application long path support also has to be declared in the applications .config file.

Thankfully this is fairly easy to do, every .Net application should have a config file that comes with it's .exe file. The config file will be located with the .exe file and it will have the same name but with a .config extension. Enabling long path support is as simple as editing the settings in the config file which should look like this:

<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false"/>
</runtime>

ArchiverFS comes set up ready to have long path support enabled, the application manifest file includes the 'long path aware' setting and it is already set to 'true'. Enabling long path support is as simple as enabling it at the OS level and editing the config file. Full instructions detailing how to do this are included in the user guide.

Long path support & Windows Explorer

So, if long path support is easy to turn on and it's supported by ArchiverFS what's the problem? Why do we have it disabled by default?

Windows Explorer, that's why. Despite Microsoft adding long path support to the Windows OS they haven't enabled it in Windows Explorer, and remember it has to be enabled at both the OS and application level.

Unfortunately there is no way to enable long path support for Windows Explorer even if you enable it at the OS level, and that makes long path support completely useless for 99% of users. Very few if any organizations are going to sanction swapping out Windows Explorer for a file manager application that supports long paths like Total Commander or Q-Dir on an organization wide basis.

Until Microsoft give users true long path support in Windows Explorer our advice is to leave it disabled in ArchiverFS. This is because ArchiverFS works entirely at the file system level using UNC paths and paths can get extended by a few characters when converting from a mapped drive (which users normally use) to a UNC path.

Handling the 0.01% of files with long paths without long path support

What’s needed is a way to shorten the path to the files without having to move the files or change the directory structure they sit in, and this is where directory based Symbolic links come in. The trick is to create a read-only folder fairly high up in the file system which will contain a few choice directory based symbolic links. These links point to places further down the file system and effectively shorten the path that ArchiverFS has to travel to reach them.

Let’s imagine you had a share called ‘Share1’ on a server called ‘Server1’ and it contained a lot of paths that were over the windows 260 character limit. Let’s go a step further, let’s look at an example path to a document:

\\Server1\Share1\Sales Departments\Regional Figures\North East\Pre Office Move 2006\Regional Subsectors\Central\Jills Annual Reports For Review\Draft Documents Prepared Onsite 2002-08-10\Cost Center Breakdown Of All Expenses By Resource Type\Spreadsheet RAW Data\New York 2002 Q1\Sector Breakdown.xlsx

That’s over 300 characters and Windows Explorer would refuse to open it. But, if we run the following from an administrative command prompt to create a directory based symbolic link in a new 'Shortcuts' folder we can shorten the effective path to this file:

MKLINK /D “\\Server1\Share1\Shortcuts\Old Sales Data” “\\Server1\Share1\Sales Departments\Regional Figures\North East\Pre Office Move 2006\Regional Subsectors\Central”

The following path will now be available: “\\Server1\Share1\Shortcuts\Old Sales Data\Jills Annual Reports For Review\Draft Documents Prepared Onsite 2002-08-10\Cost Center Breakdown Of All Expenses By Resource Type\Spreadsheet RAW Data\New York 2002 Q1\Sector Breakdown.xlsx

The new path is just over 230 characters long and as long as the “\\Server1\Share1\Shortcuts” directory is within the scope of an archive job this file and any other long path files will be discovered and archived as normal.

With the use of MKLINK and the creation of a small number of directory based Symbolic links in a shortcut folder you can easily archive every single old file in even the most stubborn and convoluted directory structures. We are keeping a close eye on the long path support situation for Windows Explorer and as soon as Microsoft enable it (or provide a way to enable it) we will enable long path support in ArchiverFS by default.