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]
As mentioned, 2002 (Build 12527.20242).
The upgrade site claims it is the upgrade for March.
But you are a special person with Build xxx78 so I'll just have to envy y'all till MS allows my kind to have this. Ah, life as an eternal have-not. Or announces it. Or it exists. Hope it does, but...
I don't believe it.
Which build of Excel? I'm using 12527.20278 on two machines and it's working fine with a file that's 245 characters long.
The same file works on another machine with 2001. I don't have anything older handy for testing.
2002 (Build 12527.20242) here as well and I tried a 245 character filename with no success.
Tried 216 name characters on a 59 character network path, "You can't save here. Please choose another location."
So neither the 218 limit, nor the 256+3 or +4 limit seems different.
Using a new directory, C:\ZZZZZZ to make it as simple as possible, I'm told "The file name i stoo long. Rename the file with less than 207 characters."
(THAT suggests a 216 character limit, not 218, but what the heck.)
So no, NOT supporting anything longer than in the past. And no proud claims by MS. Last time that happpened (change with no proud claims trumpeted the world over) I ended up with the full editing bar taking 5 lines instead of 3... yay...
I'm on 2002 and it seems to support longer paths than in the past. The error message says 260 is the limit and I have a file at 245 characters that is working now (open and save) that didn't work in the past.
No need to reinstall Excel to try it though, just switch to monthly, or the fast ring, and wait for the update.
One pin to drop would be ANY discussion elsewhere on the internet concerning happiness (and complaints about the solution, you know that'll happen too).
Did learn that people using Hebrew names are really screwed if they use SharePoint as SP "escapes" the characters making each one 3 characters long instead of 1... Da*n son... Isreal has nukes MS, just sayin', of all the people to ***** with...
Nothing new in the world outside his claim.
Daniel Ventura commented
Please provide screenshots that show this issue has been resolved. Thanks
I'd like to hear more about that "issue has been resolved" thing. We have MS not claiming it has been and an anonymous person claiming it has if you just uninstall Office and start over.
Well, not uninstalling Office on his say-so. He sounds like those people who used to bug people to get faster response in chat if they would just press Alt-F4. Just do it!
I'll believe it when a couple different pins drop. Or it works for me.
I had the same issue when on version 1908. 64-bit, semi-annual update channel.
Removed office and then reinstalled version 2002. 64-bit, monthly update channel.
Issue has been resolved it seems in version 2002. Hope it helps. Cheers.
There are 2 issues that seem to come up in the comments.
1) Ability to open any Office file including excel, word, powerpoint at all from SPO when the path is 218+ characters
2) From within Excel, being able to reference SPO files with long character paths
#1 is the most important for all of our migrations to SPO and OneDrive coming from competing platforms.
Stuart Bailie commented
2015-11-16 : Thread start
2019-02-12 : First response
2019-10-14 : Work started
Given that time line I would imagine that they are currently working to decouple the compute engine in Excel, I heard somewhere this is the actual issue. Given the many comments about this being a major under taking I honestly wouldn't expect any response until 2020-10-01 at the earliest. Yes the fix is being worked on but constant comments of "Fix this ASAP" isn't contributing to the solution. I think we should work on trying to change the ire of this thread into support for Microsoft for getting the job done and done right, as Roy below mentioned.
I agree that there is a certain annoyance with the fact that Windows can support longer file names than what Excel can but please keep in mind that this problem probably started from Excel 2.0. Observant people inside Microsoft potentially could have noticed the issue in Excel 2000, 13 years later. Yes it should have been put on the project plan for Office 2013 possibly delayed until 2016, as Microsoft does, when through testing was done between Excel and SharePoint Online interoperability but was failed to do so.
Yes please! ;)
Please fix asap!
Joseph RAVIER commented
Microsoft is selling the OFFICE365 and SharePoint solution to all companies around the world. Considering that this solution is sold as a global solution with office, it seems pretty important that excel and VBA (probably the most used tool around the world) can manage bigger path than 218 characters to make it compatible with SharePoint folders addresses length. This is a big issue. Your clients are counting on you to fix it as soon as possible. Don't let us down.
Thomson Tam commented
This becomes an unusable issue when your company move from local network folder to SharePoint with Office365.
Please fix it, now I need to make sure open file from OneDrive instead of mapping SP folder, otherwise my file will not save.
What is the update on this? We need a fix ASAP.
So much for stream of conciousness typing...
The thing is, we simply CANNOT have them hurry for hurrying's sake AND SCREW THIS UP. Think of the mind-bending nightmare that could be.
Here's an example of a teensy little thing...
SPILL functions, nice, eh? A year-and-a-half of post-announcement beta testing and:
Try "=CELL("width",A1)" with that being the ONLY thing at all in your spreadsheet. Instead of the obvious width result, 8 perhaps, you will get two cells taken by its reultS as the SPILL functionality somehow works very badly with it. What you get is the 8, say, in the cell you typed the formula into AND in the cell immediately to its right, you get "TRUE". You can make sure it's a SPILL-related problem by putting something in that next cell to the right and seeing the cell with the actual formula change to "#SPILL!".
What could "TRUE" even mean with this function? Much less as I typed it above? Yet it is there. Becomes an issue too if you use the function in a formula.
Happens if you do it CSE as well. Only using the "@" operator ("=@CELL...) makes it go away but then you lose old and new array functionality completely. And the "@" operator does not help inside formulas, just when it is the entire formula. Combining "@" and CSE gives you an array (let's say we do it horzontally, but it happens vertically as well) that is only for A1, not the A1:K1 (say) that you enter it in. So 11 8's, change the width of column A and have 11 of whatever A is now.
What the heck? Talk about a subtle and hard to expect error. A year and a half of finetuning from announcement to roll-out on my machine and I find this anyway. And utterly by accident as I tried to make a different clever idea work, only for this to fail the whole enterprise.
We do NOT want errors guys and gals. Even "subtle" errors are too massive for a subject like this.
Of course, not keeping us meaningfully updated means they are screwing themselves. If we used SharePoint or anything like it, we would move to Google and risk they were just going to decide one morning they don't want to do spreadsheets and it would be gone, no warning, only dead, insect-eyes looking at us as they said we have other things to spend resources on. But we don't use it or anything like it so...
There's no excuse since it should have been worked on back when the first PC to have >1 MB of memory happened showing how stupid it was for the video mapping to have been done in upper memory, forever cutting DOS off from simple expanding memory usage (with a switch loaded on start-up (remember that kind of thing?) that kept it turned off if one did not have memory to burn or preferred not to). That moment of that PC should have cleared programming minds forever about building in limits based upon the moment's hardware possibilities rather than allowing for natural growth/expansion/increase of capability as hardware improved.
Think of the massive problem this entails for MS. EVERY one of the 486 officially supported functions has to be tested for the ability to deal with more than today's path length. Any random function written assuming it'd never exceed (for full cell addressing) the 255 bytes plus 4 or so has to be tested to make sure it doesn't fail, especially unnoticed, in ANY way and there are plenty of ways.
Then there's other functionality to consider. How does the Pivot Table functionality handle addressing lengths? Etc.? And it must all be fixed but still allow backwards compatibility. And if they aren't absolutely brain dead, fixed with an eye toward expanded future capability not being stupidly limited but rather simply accruing to the program as the operating system and hardware become more capable.
Lord, we could even be victims of the Department of Homeland Security considering Excel to important to "idly screw with" and not allowing them to change this without being able to prove perfect improvement. I know how paranoid that sounds but you know they have a branch that oversees "food security"? Not like every child having no worries about eating today, but rather everything that could affect the production and distribution of food in America... except requiring chicken to be clean of disease slimed all over it that is, and that organic fertilizers be Pasteurized enough to keep broccoli and melons from killing us. How many other branches do they have? Lord, did I just get them thinking about Excel? Sh*t.
Of course, blowing us off and not even pointing out the difficulties they really do face is insulting and demeaning as well as utterly non-productive on their part. Whoa... looks like they've gone "government" on us...
There's utterly no excuse. But it IS a massive issue to solve (due to their laziness and stupidity over the decades — God and Vishnu, etc. didn't cause this).
Oh, and there's some evidence that the old Excel 4 macros can never be built out of Excel. If so, while they don't need to make them all work with longer path lengths, if it affects the functionality that forces those to stay alive (yay!) then that coud be another vast layer of work and complexity.
you've got to be kidding me.. this still isn't fixed?
Andrew Richard commented
I suppose the frustrating thing for us is that we were told by our IT group that if we upgraded to Win 10, latest servers etc we'd be able to forget about the file path issues (this one and the 255 or 260 or whatever) limitations. Well we migrated to the cloud and now this issue pops up. Absolute insanity. We migrated from Gsuite where we were using Drive and email. While this migration has come with a bunch of upside these are some horrible challenges to work around. We never ran into these problems with Google.....
Huge issue for us at work. I have just come across this after months of frustration. I am not particularly techy but nobody has resolved this for us at work and it is wasting so much of my time. I had reported it to management without understanding why the issues were occurring so I’m looking for myself. I can’t believe this was originally posted in 2015 and the Microsoft Excel Team responded in 2019 (!!!!!!) to say they are working on it! I’m disgusted and shocked! What on Earth do businesses pay their money for the licence for if not a useable system. This is having a massive impact on productivity. I hope this is resolved soon but I am not holding my breath. Yours, disappointed.