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/office_2013_release-excel/sorry-unable-to-find/595333d0-1463-499f-967e-4da8ac2e2047
Thank you for your input on Excel’s filepath limit! We have included this feature as part of upcoming work.
David [Microsoft Excel]
I have a way to solve: I map my own C drive as a mapped drive, but lower in the folder hierarchy.
Map drive \\computername\c$\Users\Box_sync\Loooooooong_name so the path look smaller for excel.
Just in the last couple of days Excel has shortened my acceptable file length to around 21 characters...no changes in software or hardware. Why?! This is maddening!
Have an even more bizarre problem, though the 218 character limit is also annoying. But for one client - and one only - I am reduced to file names of only around 21 characters. Anything beyond that Excel refuses. Very hard to make meaningful files names w only 21 characters.
Seems to be movement in the latest Excel (Office 365 Subscription) or Win 10 (not sure which). Just opened an Excel file with a 247 character full path length (excluding filename). Once opened, in Excel the recent files path shows in the old DOS short format (e.g. COMPAN~2 instead of Company Files). Behaviour is a little strange still though as at one point while testing various combinations the 218 character warning returned....work in progress?
Not sure when changes occurred however the test device is running Windows 10 1809 Build 17763.107 and Excel 1810 (Build 11001.20074 Click-to-Run)
Tim Jarrett commented
Microsoft are not listening.
This might not have been a big issue in the past, but with Office365/sharepoint/MyDrive it does become a disrupting limitation. When you check the filename length on your local filesystem, it looks like you do not exceed the 218 limit since the base part consists of 'C:\Users\<username>\OneDrive - <companyname>\' which is about 35 to 50 characters. But that is not the filename used to open the file since Office will try to open it from the network location. And that starts with 'https://<companyname>-my.sharepoint.com/personal/<email without special characters>/Documents' which results in about 80 to 100 characters, so almost half of the allowed 218 characters.
In short, this is pathetic. FIX IT!!!
Funny, I spoke to the Office guys at Ignite at the Office booth and they weren't even aware it was a problem... shows how useless this Uservoice stuff is.
I am using Office 365 and all my files are on SharePoint.
I am also facing this problem too. 218 characters is not enough.
Also I noticed that in the URL has some repeated info such as https://mydomain.sharepoint.com/Mylibrary/Forms/Allitems.aspx?viewpath=Mylibraryaspx&id=Mylibrary
The path for "Mylibrary" is repeated 3 times, which takes one-third of my total path lengh.
Is there a way to improve the URL so that it won't repeat library path three times and increase 218 limit?
Jos Lieben commented
I wrote a powershell script to automatically identify files that exceed this length in Sharepoint or Teams: https://www.lieben.nu/liebensraum/2018/10/finding-files-in-sharepoint-online-or-teams-that-exceed-218-path-length/
If you would all just name your files as spreadsheet1, spreadsheet2, spreadsheet3.... etc instead of trying to give them a useful and meaningful name, then you wouldn't have this problem.
Obviously it gets a bit messy when sharing files with other organisations etc who might already have a "spreadsheet24", but there must be a workaround.
Maybe there could be a central control to issue names, in a similar way to MAC addresses.
Then we could leave MS alone and stop bothering them with all the shortcomings in their software.
Stuart Bailie commented
Bruno I like your idea that they should "prioritize this fix" but the bigger issue is they have to start with acknowledge that it is broken in the first place and that methodolgies from the 1990s don't apply to late 2010s era of computing.
Bruno Simon commented
We are gradually implementing the use of SharePoint Online libraries in the entire organization and certain departments heavily use Excel. The 218 character filename length limit is the most prominient problem we have encountered this far. Please prioritize this fix.
Jesper Säilä Larsen commented
Come on MS! We need this! Please fix :)
Auke Briek commented
To quote someone below: "Better yet why hasn't Microsoft replied to this thread yet?" A reply would be very much appreciated!
J. Everett Hale commented
I had been putting up with renaming filenames at work whenever the path had become too long when working with files in our network. Eventually however, I came to the point where I could not open a file whatsoever. What I mean is, even when the Excel filename was 1 character long, it would not open. On top of the obvious things wrong with this issue that has been explained by many others a multitude of times, it's ridiculous that an Excel file can actually exist in a folder with a separate filename character limit, but isn't able to be opened because it has a separate, archaic character limit.
Is it really that hard to change the data type from char to literally any other data type? This is day 1 programming class stuff. You should be ashamed. After using Excel for 10+ years, you are forcing me to use another program. Are you happy now?
Yup, still an issue to this day, 3 years after the initial request. Come on Microsoft, this is a biggie.
Sorry, but it cannot be true that this issue is still present.
Looks like all the programming effort went in the new (and, by the way, quite annoying) optical redesign and additional (even more annoying) online functions.
Use Libre Office. It doesn't have this problem.