Increase the 218 character filename length limit to open files in excel
Excel can't open files with full path lengths greater than 218 characters as documented in https://support.microsoft.com/en-us/kb/213983. This is still a problem in Office 2016. It seems crazy that Excel can't open a valid file that the filesystem allows. People have been complaining about this since Office 2000. The thread below has over 11 thousand views and there are plenty others. Please fix this. http://answers.microsoft.com/en-us/office/forum/office2013release-excel/sorry-unable-to-find/595333d0-1463-499f-967e-4da8ac2e2047
I am excited to announce that we have completed the work to enable longer file name and paths in Excel for desktop. This was a significant change that required work on multiple parts of the product beyond open and save, since the file path is used in other features like external links.
Before this change, Excel for desktop could open and save files with a full path length of up to 218 characters.
Starting a few weeks ago, all Office 365 users in the monthly channel (CC – current channel, build 12624.20466 or above) are able to open and save files up to 2034 characters. However, in practice there are lower limits imposed by the file system:
- Windows local and UNC files: 260 characters
- OneDrive/SharePoint files synced to the local drive: 260 characters
- OneDrive/SharePoint files opened directly from the cloud: 400 characters
Thanks again for your continued feedback.
David [Microsoft Excel Team]
You may have solved the problem, but you are still displaying this limitation in the message box.
Is there any good reason for not allowing some of the special characters?
It seems that Excel is capable of loading a file with special characters (brackets  in my case), but doesn't seem to be capable of saving a PDF file with the same name.
What is long path tool???
can it help or fix this problem?
Any chance the Word version of this error can get some love? Major issue for us and out clients.
@Roy thanks. Excel might support long path names now but everything else that the users use (like the File Explorer) seems still restricted to 260 which doesn’t help anyone :/
I have Build 13029.20344 so definitely later than the build "David" refers to as the starting Build to have the new abilities.
However, my File|Save As dialog box will only physically permit EXACTLY 259 characters. And even filled to its limit, it won't process that name.
Tells me it can't save it becauise the filename, directory name, or volume label syntax is incorrect. Untrue, of course, but that's the message.
At exactly 250 characters, that changes to a different message box and the dialog box even reacts differently after acknowlodging it... It becomes you can't save here, please choose another location.
Clearly, after reaching 250, it's adding in path length and having an issue. But it won't even consider other factors above 250.
At 200, it saves. I did not test further to see where, between 210 and 216 it was willing, but somewhere there. Path length is 47 characters, plus the five for .xlsx, so that's 262 total, or a wee more... perhaps the 260 he talks about though why higher, not exactly or slightly lower?
So for SAVING, LongPathsEnabled seems to get me nothing. The increase "David" mentions, to 260, seems to be all I get.
Opening though... I can't tell. Somehow, now, and not months ago, all the really long filenames I try get truncated. I did an 800.3 filename then and had the same kind of varied result I;'m having today. I got the length because after getting the file system to take the name, I did another rename and copied out the name, then put it into Excel and did LEN(). Wasn't hand counting 800 characters.
But today, all I get is 183 or so characters. Renaming simply truncates the paste at that. Another 58 characters for path, 5 more for .xlsx, and I have perhaps 246 characters: because even Windows won't let this work. Which is likely what "David" was referring to.
Side note: I have that little down arrow too.
I'm thinking something strange and different is afoot given that Explorer is what was truncating the file renames, not Excel. I no longer believe LPE is enabled enough to work. So I have nothing further at the moment to add, helpwise. I'll see where further investigation takes me, but... I don't expect happiness at the end of this tunnel.
@Roy - I still get the error opening a filepath with 273 chars
Yes, there is an additional step:
"Enable Win32 long paths" in the Local Group Policy Editor
Do this by clicking the "Start" button (I'll call it that until death I suppose, whatever MS calls it currently) in the lower left corner of the screen (usually), type "gpedit", and open it when done typing.
(I have seen the internet say the editor is only available in Windows 10 Pro. When wanting to do it, I feared I would have to involve IT and argue for it, but it works from here and doesn't even require Administrator priveleges, or opens with them by default.)
Once open, navigate to: (double-click on)
1. Computer configuration (in the tree on the left)
2. Administrative Templates (over in the working area to the right)
In Filesystem you will see "Enable Win32 long paths" — click on it and enable it.
I have attached a screenshot of the point at which you select it.
While there anyway, you might want to navigate about some other options. I found a couple that were hard to interpret without thinking that ALL my efforts at using privacy options in Windows provided software, including IE, had always been worthless because the settings here were not enabled. That they provided the fiction that you were protecting yourself but because you never knew to come here, nothing much actually took place outside some (ineffective) things like deleting cookies and such.
Anyway, without doing this step with "gpeditor" the Registry entry will do no good. It seems.
I am still getting the error even I updated to the latest CC update channel. I enabled Longfilepath reg key in windows 10. Am I missing something???
Does this new limit of 2034 characters apply also for the 32 bit version of Excel in Office 365 build 12624.20466 or above
By using Long Path Tool, I fixed windows files issue
Michael Durand's comment spurred a search on my part that must have been different from my previous searches 'cause I came across a Microsoft document on the subject that did not say it as a particular point, but did talk about Windows API32 and Shell limits now being whichever setting you have, either out-of-the-box (=260 characters) or the NTFS limit now possible in Windows (=32767 characters) settings, for MAX_PATH length.
It also talked about UNC aspects, including some limitations and behaviors, and the two pieces together give me the impression that "David" (when he states the first limitation in his comment above) means exactly this, essentially the MAX_PATH length, and so:
1) IF you have set your system for the 32767 limit, and
2) IF the program of interest is manifested (and includes a statement allowing the longer paths — just being manifested is not enough),
then the limit "David" mentions should be 32767 characters, not 260 characters.
However, even if you set your system and the program is manifested with the statement for this, you could STILL run into issues depending upon how it actually interacts with the file system for each kind of interaction. If it interacts for whatever via the Shell, it could limit that interaction to just the 260 character limit, although other places I've searched say that the Shell started being able to accept the MAX_PATH length sometime in 2016, though no one talks about the "except's" that probably exist. However, any new program ought to (you know, you really wish this were so, right, since it means people are just stupid if not so) perform all tasks consistent with the longer paths so long as it also allows them in general. But older programs, like Excel, might have lots of un-modernized code so...
Also, the document included the point, not emphasized, just included, that the filename itself, irrespective of any allowable total path length, cannot be longer than exactly 260 characters. So while your PATH can be VERY long, the filename itself, cannot be. Not usually a problem for our needs HERE, but good to know. Also, regardless of your path's allowed length, but particularly for the short, default, setting of 260 characters (256 plus some "faux" bytes), you CANNOT use so many characters in the PATH portion that you end up with less than exactly 12 ("8.3") characters left for use by the filename (even if the filename is actually shorter than that). Seems a good chance many refusals by Excel that are bizarre-seeming could be subject to this.
(I'm still imagining the second and third limits he mentions are really One Drive and SharePoint limits, not really Excel's although Excel might enforce them to avoid nasty surprises for users. Of course... who knows, right?)
Well, all that, and still... if it were so, why would they be cagey about it instead of braying it about everywhere? So...
Michael Durand commented
Thank you ; anyway the limitatino on Windows local files is not really an Operating system limitation, becasuse there are all the functions in the Windows SDK to access files with very long path... It is mostly a matter of adapting the Office suite to use these functions... In the meantime, this limitation is so frustrating...
Actually, that link below is a good thing. Used to be the fully resolved path was the length but now it looks like OneDrive and SahrePoint only go back to the URL.
When he says "Windows local and UNC files: 260 characters" is only being enforced by the file system, NOT by Excel itself, that's also good because you can increase the file system's limit to 32,767 characters. I bet there's a far lower limit still hard-coded into Excel that is much, much lower than that but still it's something more.
They cannot have done more than cosmetic change, like suppress Excel evaluating the length and refusing before ever presenting to the file system. So chances are there are secondary limits they will only be finding out about from people complaining (certainly not from analyzing code from 37-38 years ago). So people need to experiment! And complain! I mean, report their findings. Sadly, for MS, that is the same thing as no other avenue is available to most.
Regarding your stated limits for "Windows local and UNC files", is this only individual filename or foldernames, or does this limit apply to the total file path?
The link below seems to indicate that the 260 limit applies to individual foldername and filenames, whereas the full path limit is 400.
Raju Alluri commented
When we save the file system dont give us any errors and when we download the file it does, its so frustrating that we already have multiple nested folder and user saved the links as favorites. Now restructuring the folder by manually calculating the url limit is not the reality. Microsoft should come up with some kind of workaround by shortening the URL if its crosses the said limit.
Does anyone know when this will be fixed in the semi annual channels?
Something from the link Anonymous gave... MS fixing Word problems that we in Excel can only DREAM of having:
"We fixed an issue where files with long path names (greater than 32K) would not open and an appropriate error message was not being displayed."
(Sigh...) Those poor folks with path names longer than 32K who couldn't open their files and no message was even being given to them... those poor, long-suffering souls... it must've been just awful. Just awful.
Gosh, maybe it makes me glad we in Excel don't face such concerns. You know, "maybe."
I think I could live with a real limit of 32,767 characters, if I had no real choice. It could be better than 218 or 260... but gee, with no error message if I went over? The horror...
Could we get maybe one or two of Word's project managers on the Excel crew? I have the feeling their take on customer service is different than we here are used to. A LOT different. On the other hand, it just might ruin them instead, I guess. I've noticed the outside world for about 50 years and a major mouthwash company has repeatedly ("almost constantly" would be valid, almost) been fined for claiming they "kill the germs that cause bad breath" that whole time, so perhaps corporate philosophies don't ever change. Yay. Still, I'm selfish enough to see the experiment tried.
Why is there no mention in Office 365 release notes about this fix (on Microsoft web site)?
@Justin: I created a file with the name 1234567890.txt, then renamed it:
which is an "800.3" filename... Notepad would not save it as that, but I used Explorer to serve up the file and rename it and it took the name change nicely. Then Notepad was able to open it, which seems interesting since it would not save it as such. Hmmm... should've tried saving the existing file, see if it was just creation it would not do, or saving in general...
It saves it. So it won't create one with a name that long, but it will save it. Word opens it nicely. Excel... nah, and tells me some reasons why it's probably my fault...
Along the way, "Copy CON" in a command window would not save the file with the long name. Won't seem to open it either though I was not exhaustive testing that.
So I believe I can say Explorer seems to work with it with the feature enabled. And it presents no problems for normal day-to-day use. I've used it for three years now, second computer with it though both were Windows 10, with no identifiable problems.
Excel appears to "do it all on its own" though, surely a relic of the days when neither DOS not Windows could be relied on for adequate services. My believe, given the recent claim, has settled to the idea that they still have not or cannot replace the basic funcitonality ("yet"... hopefully) but someone got clever and found a way to at least allot the entire 256 (+4 pseudobytes) to the path rather than having to reserve some to the internal path (sheet, row, column... absolute, relative... etc.).
But to move forward with certain products of the SharePoint kind, they HAVE to solve it or lose out. I do believe they couldn't care less in the long run as I believe they desire us to all move to Power BI so as to force us then into Power Apps so a spreadsheet creator/maintainer and 5 users stop being a person already paying for Excel and 5 others already paying for Excel ven though they use 11 spreadsheets, not just one, and become a set of those (STILL already paying for Excel) now paying 6 license fees every month... for EACH of the 11 apps that replace direct use of the spreadsheets and so now taking 6 license fees for Excel and 66 more for the 11 apps multiplying earnings by 12.
But to addict people to the necessary functionality, SharePoint is an easier "gateway drug" to sell, then on to the hard stuff with the Power BI, then Power Apps pathway. Thing is, if your gateway drug (SharePoint) sucks at showing off the concept, well, that won't work. So they need it to work and not shock people with the immediate idea of slowly doing away with Excel. So... maybe they will someday figure a fix for it.
If they could just overcome the insistence upon changing a specified path to a fullblown literal path so we could alias source with drive names, say, all the world would be able to sigh contentedly, carp a little bit about "well WE aren't allowed to do that", and move on. But... hopefully... baby steps...
@Gary - from what I can tell that doesn't work for Windows Explorer. It works great in Powershell though. Why is explorer missing the long path aware statement in the manifest? Either I'm doing something wrong or Microsoft needs to get that working before it's even worth bothering to make Excel open longer paths?