If you work with Windows long enough, especially with folders and files that have long names, you'll run into a bizarre error: Windows will report that the folder path or file name is too long to move to a new destination or even delete. What's the deal?
Hey How-To Geek!
So the other day, I was reorganizing some files on my computer, creating folders, that kind of stuff. Then, when I was moving some files into a folder, I get a message, stating that the resulting folder path would be too long. I was confused. I know that every single OS since DOS supports Long Filenames, yet Windows claims that the path is too long? Why does this happen?
Sincerly,
Mr. Disorganized
The problem you're running into is an unfortunate intersection of two systems that, in cases like this, yields an error. To understand exactly where the error comes from, we need to dig into the the history of Long Filenames (LFN) and how Windows interacts with them before we delve into solutions.
Long Filenames were introduced, through the underlying MS-DOS architecture, in Windows 95. The new LFN system allowed for file and directory names of up to 255 characters. This was a welcome expansion of the previous file name system, usually called 8.3 filenaming because the name was limited to eight characters and a three digit extension, but also known as Short Filename (SFN). As you can imagine, back then there were still a lot of DOS-based apps around and there were more than a few headaches trying to get the newer LFNs and the legacy SFNs to play nice with each other. If you've ever come across an older diskette or CD-ROM with oddly truncated files on it (like abcdef~1.txt) that filename was cut down by some SFN-using legacy application from some longer and unsupported LFN (like abcdefghijk.txt).
We're a long way from the mid-1990s, however, and the whole Long Filename thing is (for the most part) firmly ironed out. If you're running a version of Windows from the last 10 years, you've likely never even come across a filename length conflict like we we used to run into back in the DOS/Windows 95 days. That said, we still run into hiccups, as you discovered with your disk cleanup project. But why? If Windows' Long Filename system supports folders and file names of up to 255 characters per component, what wall are you running into? We can't blame NTFS (the filesystem that the vast majority of modern Windows machines use) as NTFS will support a chaining of folders and file names up to a total path length of 32,767 characters. That far exceeds the typical directory structure most users would ever need.
Where it all falls apart is an artificial restriction Windows stacks on top of the LFN/NTFS system: the MAX_PATH variable. The MAX_PATH variable specifies that a complete directory structure in Windows can't exceed 260 total characters, including the drive letter, colon, backslash, and null backlash at the end. Thus you only have a potential real MAX_PATH of 256 characters, e.g. C:\your-256-character-path\.
So what happened when you were cleaning up your computer is that you had a directory with an already long path (either because the folder names were long, the file names were long, or both), and when you attempted to move one or more of those directories into another directory with a long path, the total length of the path name exceeded the 260 character limit imposed by the MAX_PATH variable.
Now, you may be thinking "Ah-hah! We'll just change the MAX_PATH variable and solve the problem!" Alas, it's not that simple. Not only is the MAX_PATH variable essentially hard coded into Windows, but even if you went through the enormous hassle of changing it, you'd end up breaking so much it wouldn't be worth it. Too many applications expect the path variable to be what Windows has long specified it to be. We can't just go around changing it without creating an enormous mess.
Where does that leave you? Well, the simplest solution is to just edit the path data. For example, if you have a ton of saved articles where the application/extension you used to save them from the web created a directory that was the full title of the article + the article lead, and then the file name itself is the full title of the article + the article lead, it would be really simple to hit or exceed the MAX_PATH with a single save. Editing those enormous folder and article titles down to a more reasonable size is an easy way to fix the problem.
If you have a huge number of files with a long path and you don't want to edit them all (or if you want to delete a ton of old directories that are too long for Windows to deal with when restricted by the MAX_PATH variable), there is a command-line work around. Even though Windows is restricted by the MAX_PATH variable, Windows engineers realized there would be situations wherein users would need to deal with longer path names. As such, the Windows API has a function for dealing with extremely long paths.
In order to take advantage of that API and use command line tools on your unwieldy folders/file names, you simply need to append the directory name with a few extra characters. For example, if you had a huge directory structure that you wanted to delete (but received an error due to the path length when you attempted it), you could change the command from:
rmdir c:\documents\some-really-super-long-folder-name-scheme\
to:
rmdir \\?\c:\documents\some-really-super-long-folder-name-scheme\
The key is the addition of the
\\?\
portion before the start of the file path; this instructs Windows to disregard the limitations imposed by the MAX_PATH variable and to interact with the path you just supplied as supplied/understood directly by the underlying files system (which can clearly support a longer path). As always, exercise caution at the command prompt to avoid accidentally deleting files or directories you intended to leave intact.
If our overview of this issue has you curious, definitely dig into this article from the Microsoft Developer Network library, Naming Files, Paths, and Namespaces, for more information about what's going on under the hood.
Have a pressing tech question? Shoot us an email at ask@howtogeek.com and we'll do our best to answer it.