Find out if Windows file paths exceed the 260 character limit
There is a good chance that Windows users come into contact with the operating system's 260 character limit for paths. A common scenario may occur when files get deleted on the system. If the path exceeds the limit, the files cannot be deleted and Windows will display an error message.
Microsoft did add an option to Windows some years ago to extend the path limit, see Microsoft ends the 260 long path limit (sort of), but support has not been added globally up until now. In other words: there is a chance that you may still run into the Path limit on Windows machines even today.
Third-party tools have been created to resolve issues linked to the path limit on Windows machines. We reviewed Long Path Fixer in the past already; this time, it is Path Length Checker which is a reporting-only tool but still useful.
Path Length Checker
Download the latest version of the program from its GitHub repository site. You need to extract the archive once it has been downloaded and may run the GUI version of it afterwards to get started.
All it takes at the base level is to select the starting directory, e.g. drive c: or a folder on any of the connected drives, and select the "get path lengths" button once the selection has been made. The dragging & dropping of a directory on the program window is also supported.
The crawling may take a while to complete but the speed was acceptable during tests (never longer than a few minutes).
Results are displayed in a table and you may click on the column headers to sort the data accordingly, e.g. by path length. The output can be copied to the clipboard; for this, you have to select one or multiple entries and the "copy paths to clipboard" option. A click on the down-arrow icon next to the button reveals options to save the selection to a CSV file.
Long Path Checker supports crawl and search filters that you may make use of. Apart from selecting the starting directory, you may also set minimum and maximum path lengths, disable the inclusion of subdirectories, and exclude files or folders from the crawl. You may also use a search pattern and have the program return the starting directory in the output with a string.
Long Path Checker includes a command line version that you may run, and a PowerShell script to run it from PowerShell.
Closing Words
Long Path Checker is a handy tool to check Windows directories for potential path violations. It is handy for developers, system administrators, but also home users. Downside is that it does not include any options to resolve issues associated with paths on the system.
Now You: Have you run into long path issues in Windows before? (via Deskmodder)
Will PLC include Dropbox files if these (and the folders they are in) are “online only”? I assume the answer is “yes,” as the path still exists locally, but I need to make sure. Thanks!
Regarding the 259 vs 260 characters length discussion:
Just try it for yourself. Issue the following commands in PowerShell:
> CD C:\
> md (“_” * 244)
> cd .\____
(use tab-completion)
> out-file .\90123456789
> (gi .\90123456789).FullName.Length
> out-file .\901234567890
You will see that the max length path you can create is 259 chars.
The 260th “character” is the null terminator that is used for internal bookkeeping and not part of the actual fully qualified file name (it is not a “character”).
So, even the title of this article has it wrong :-) (just like a lot of other websites)
(BTW: I shouldn’t have posted my “mnemonic formula” to remember the 259 limit; it might cause confusion. Unfortunately editing your post is not an option here).
@Maarten:
Thanks for clarifying the “null-terminator exclusion.” It looks like I at least got the “old limit” right: the old MAX_PATH was 256 so the maximum number of actual characters in a pathname was 255. I think. ;-)
In this connection, it looks like (recent?) versions of Word, PowerPoint, and Access might be subject to the “new” 259-character pathname limit even if LongPathsEnabled is enabled, and that Excel 2010 is actually subject to a 213-character limit. See:
https://docs.microsoft.com/en-us/office/troubleshoot/office-suite-issues/error-open-document
I wouldn’t necessarily take the article (dated 3 September 2020) as gospel — its “Applies to” section doesn’t specify which versions of Word, PowerPoint, and Excel it covers — but if I still used MS Office, I’d at least keep the possibility in the back of my mind.
I’ve run into this problem a number of times, usually because I downloaded a file with a really long original filename without bothering to edit it down, into a folder with a longish path, subsequently edited the file, and then had an automatic syncing routine generate a versioned backup of the original file with a timestamp appended to it … often in a folder with an even *longer* path than the original file’s. (I’m still not entirely clear on how a properly designed filesystem can allow a file with a filename or pathname that’s “too long to be deleted” to be created in the first place … but I’m just a user, not a filesystem designer.)
These problems haven’t happened often enough for me to remember how I dealt with them. I’m pretty sure I used a utility called something like “too long path detector” at some point in the past, and I *think* the way I deleted, moved, or renamed too-long-pathname files was to rename folders higher up the path with shorter names. I think I’ve used some tricks from the command line a couple times, as well.
Currently, I see that have LongPathsEnabled enabled in my registry, and I don’t think I run any legacy programs that weren’t designed to support long paths, so it’s not really an issue. I don’t remember whether LongPathsEnabled was enabled by default in Windows 10 1903 or whether I changed it, but it’s enabled.
Regarding Everything, len:>260 just finds *filenames* (exclusive of path) that are over 260 characters in length. If you want to find *pathnames*, the syntax is path:len:>260. Also, 260 being the maximum “MAX_PATH” length, not the shortest “illegal” path length, I think >260 (not 259) is in fact correct. Additionally, because legacy 32-bit Windows programs and utilities may have been designed with the older 255-character (?) pathname limit in mind, path:len:>255 *might* be a safer bet, if compatibility with legacy 32-bit programs/utilities is what you’re checking for.
Finally, Voidtools’ Everything search utility is indeed *awesome*. It has officially become the Windows-only program I miss the *most* in Linux. I gather there is now an Everything-inspired search utility for Linux that’s in late beta, called FSearch. But from what I’ve read, Everything’s insane speed depends on file-metadata tables that are specific to NTFS and not present in … many? most? all? … Linux filesystems, so I’m guessing FSearch has to build its *own* extensive file-metadata tables and keep them updated in real time. I’m looking forward to trying it out when it starts hitting the repos.
Anyway, there are a few reasons I’m not yet running Linux on my new laptop (concerns about battery and thermal management on very recent hardware among them), but for now, not being able to run Everything is WAY, WAY up on the list. I have unhappy memories of waiting FOREVER while Catfish, Drill, or Recoll rebuilt their indexes and/or ploddingly proceeded with their searches, whereas with Everything, BAM! — the results are just *there* … *instantaneously* … *every time*. It’s a truly *invaluable* utility, and the more of its syntax you learn, the more invaluable it gets.
I assume the following information is valid and reliable and easy enough for anyone running into the problem mentioned:
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/
Yes? No?
Not sure because I’ve never had the problem.
For those of us who have the Everything search tool ( https://www.voidtools.com/ ) already, simply do this search:
len:>260
Actually, you should use path:len:>259
If you use len:>260, you get the length of a single folder- or filename, without it’s path.
So for c:\long foldername\some file.txt, it will “measure” the length of ‘some file.txt’
(And for NTFS and FAT(-32, -64) this is hard limited by the filesystem to 255 characters; ReFS is limited to 32K length for a filename, btw)
259 is the max length for a “non-long path”
(C:\ + 255 + internal closing character = 3 +255 + 1 =259)
So you can search for:
path:len:>259 (larger than 259)
-or-
path:len:>=260 (260 or larger)
And I agree: Everything is awesome! :-)
Great tip, Everything is awesome! Here is my review: https://www.ghacks.net/2017/06/07/everything-desktop-search-review/
Missing link? It says in the article : “Microsoft did add an option to Windows some years ago to extend the path limit, see Microsoft ends the 260 long path limit (sort of), ”
Was there supposed to be a hyperlink on “see Microsoft…”?
Yes, sorry for that. Added, and here it is: https://www.ghacks.net/2016/05/27/microsoft-260-long-path-limit/
You can program this in python with 5 lines of code :-)
—————————————-
# search windows c and list path with long filenames
import os
for root, dirs, files in os.walk(“C:\\”):
for file in files:
if len(root + file) > 255:
print(root + file)
You mention 256 once and then 260 for the limit. Which is it exactly?
It is 260 according to this Microsoft Doc: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
I’ve had my fair amount of trouble with long paths / fiel names. Apparently, that issue isn’t present on ReFS volumes — ie on a file system MS doesn’t want us to use.
Thank you for the article. I’m going to scan my system, now that I was reminded on the problem.