Long Path Checker
Fermina Enge
I'm using a xcopy in an XP windows script to recursively copy a directory. I keep getting an 'Insufficient Memory' error, which I understand is because a file I'm trying to copy has too long a path. I can easily reduce the path length, but unfortunately I can't work out which files are violating the path length restriction. The files that are copied are printed to the standard output (which I'm redirecting to a log file), but the error message is printed to the terminal, so I can't even work out approximately which directory the error is being given for.
I've also written and blogged about a simple PowerShell script for getting file and directory lengths. It will output the length and path to a file, and optionally write it to the console as well. It doesn't limit to displaying files that are only over a certain length (an easy modification to make), but displays them descending by length, so it's still super easy to see which paths are over your threshold. Here it is:
Crazily, this question is still relevant. None of the answers gave me quite what I wanted although E235 gave me the base. I also print out the length of the name to make it easier to see how many characters one has to trim.
As you can see from the screenshot above, the Name Len tab of the file rule editor specifies is configured to match paths with more than 255 characters in them. Also note that the Count the full path length option is selected (without this, only the length of the file name would be considered when evaluating the rule).
So there you have it, a quick and easy-to-use means of finding long NTFS file system paths. Very handy considering that a number of programs and systems are unable to process long file system paths correctly.
The Windows path length only refers to apps using some of the api set. Applications that use unicode api can extend the path length to 32,767 characters ( Naming Files, Paths, and Namespaces - Win32 apps Microsoft Learn ). Most current application, including Unitrends, no longer have issues with long path names.
Some interfaces in Windows still use the standard API and will limit you to 256 character paths, but you can bypass this using \?\c:. I used to create long paths to test management, monitoring and security applications. Its easy to do, create a path close to 256 characters, then share it. Map a drive to a share, then keep going.
You can use vbscript objFile.Path and use string manipulations to get the path length. I was about to write up something simple, but found something that looks fairly complete from a resource I use frequently:
In my organization, while IT manages networked drive backups, local drive backups are the user responsibility. I xcopy my local Windows XP hard drive to the network drive weekly using xcopy with the /D switch. I have never failed to find what I need when searching the shared drive, but one always wonders, can you be absolutely sure that an xcopy based back-up to the network is really reliable?
A quick work-around to rapidly find and correct the 100 or so path length problems (as it turned out) was to cmd, dir >temp.txt, import the temp.txt directories into Excel, use formulas to append the appropriate directory onto each filename, and length test the resultant string. Excel allows you to search for only the exceptions and then to hyperlink to the offending directory, which is not terribly inefficient. Then manually minimize filename and folder name lengths starting with filename and working backwards until each fits within 250 or so characters.
What you can do is grab the NTFSSecurity module (Import-Module NTFSSecurity), which contains a Get-ChildItem2 cmdlet. It works the same as Get-ChildItem, but utilises a third party DLL to handle longer paths as well.
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)
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".
The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.
There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.
Understand that enabling this registry setting will only affect applications that have been modified to take advantage of the new feature. Developers must declare their apps to be long path aware, as outlined in the application manifest settings below. This isn't a change that will affect all applications.
The registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1. The registry value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (see below for the list of functions). The registry value will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value, a reboot might be required because some processes may have started before the key was set.
These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.
These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.
When you're moving a OneDrive site from your source to the target environment, the OneDrive URL changes formats. On the source platform, the OneDrive sites are in the format of _user. On the target platform, the Domain_User portion of the URL changes to use the UPN for the user. This looks similar to _contoso_com.
We have identified four different locations in which failures are likely to occur due to long URLs. As a result, we have four different reports concerning long URLs. The Scan Result Reports section covers each report along with the remediation that needs to occur.
This scan results in four output files. Each file is for a specific long URL issue that will result in migration failures. LongODBUrl-AllDocs-detail.csv There are two limitations related to the length of the path to a given file:
If there are files listed in this report, the owners need to move the files to shorter paths or delete the files. For example, they could move ProjectA.docx up to a folder directly under Documents, or they could delete the file if it's no longer needed.
For example, you have a OneDrive site at _bobsmith. That site has a link in the Quick launch named Reports and the URL of the link points to _bobsmith/documents/folder1/...folderN/Reports. During the migration, SharePoint updates the URL to point to /bobsmith_contoso_com/. The extra length added to the URL may result in the length being over 260 characters, which will cause the migration to fail.
LongODBUrl-Perms-detail.csv Permissions that are set on an object in SharePoint are tracked by the URL of that object. If you set permissions on a folder, SharePoint stores the relative path to the folder. If you set permissions on an item, SharePoint stores the server relative path to the item.
LongODBUrl-Deps-detail.csv Certain files can have other dependencies. Those dependencies are tracked by the URL. During the migration if the dependency information is too long, the migration fails.
FullURL has a limit of 260 characters. This is the file with the dependencies. To remediate if the FullURL is too long, either remove the file or move the file to a location closer to the root of the site collection.
DependencyDescription has a limit of 270 characters. This is the dependency associated with the FullURL. To remediate the DependencyDescription, either remove the dependency or move the dependency closer to the root of the site collection.
4a15465005