6 ms·

Excel can't save to paths over 218 characters

54 points by glennos 13y ago

Patrick_Devine 13y ago
Ah.. the old 218 characters in your path problem! Because of course!
- tanordheim 13y ago
  Visual Studio (at least 2010 and 2012) also has this problem, actually. If the path (including filename) to your solution file is more than 218 characters, it refuses to work with it. Welcome to 1995!
- kristopolous 13y ago
  It's MAX_PATH in Windows (== 260. There's a 32K Unicode-equivalent limit[1]). In Linux it's PATH_MAX, which is (very likely) 4096. That's a bigger number than 260, sure; but it's still a discrete one; instead of, say, ∞. --- [1] 'To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".' http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
  - homeomorphic 13y ago
    You mean finite, not discrete :-)
  - thristian 13y ago
    For reference, the GNU Hurd kernel was designed to avoid fixed limits like PATH_MAX. As a result, they have reaped endless compatibility issues with software that assumes there will be some specific fixed limit: https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html https://www.gnu.org/software/hurd/community/gsoc/project_ide...
    - yk 13y ago
      And another proof that GNU Hurd is superior to every existing OS.
- sgift 13y ago
  MAX_PATH, bane of my existence. I cannot count the times a customer did not find a document in search because Windows decided to throw this limit in our faces. It can pop up at the weirdest places ...
- starky 13y ago
  I'm pretty sure I said this exact same thing when my boss finally figured out that this issue was causing a script we use to fail on the BOMs I was trying to release. It took an embarrassing amount of time for a few engineers to figure that one out.
- randuser 13y ago
  My favorite experience with it was trying to deal with a zip file of "C:\Documents and Settings\" from an old computer that happened to contain multiple files whose paths were 255 characters long or so. You couldn't unzip it in a subdirectory of "C:\" because one of the resulting paths would be too long and cause the built-in zip program to crash/fail entirely. Using 7zip was the eventual solution. On a related topic, do you know how difficult it is to search for files whose path are above a certain length on a fresh/default Windows setup? I eventually resorted to installing Python on it just to write a script to do it.
cstrat 13y ago
C:\not\sure\about\the\rest\of\you\but\i\needed\to\see\how\long\that\is\to\fully\understand\the\implications\of\this\seemingly\arbitrary\limitation\-\to\give\this\some\context\this\path\is\two\hundred\and\18\characters\
- gilgoomesh 13y ago
  When the names mean nothing, it's harder to gauge. Here's a believable directory structure that might lead to the problem: C:\Users\reasonableusername\Documents\Work\CompuGlobalHyperMegaNet\Non-Project Documents\Administrative\Business Contracts\Fiscal 2013\First Quarter\February\Week Two\TPS Reports Cover Sheet And Memos Template - 3.xls
  - glennos 13y ago
    Yep, that's the sort of project path structure which was causing me grief. Excel then gave me a warning with a list of 6 possible issues, none of which mentioned the 218 limit.
  - pyoung 13y ago
    Yeah, I have seen it first hand. Admittedly, there was some redundancy and some excess in the folder names, but it was for a relatively large project that was organized with fairly deep levels of sub-projects and tasks. If you happened to be working on one of the sub-projects that had a longer, more verbose title, you would run into this issue.
    - agumonkey 13y ago
      Social implications of a size limit can be quite large. Non tech saavy team forced to restart work (half of them will lose the file if saved in a temporary location) after waiting for someone to explain them this additional rule.
- lifeisstillgood 13y ago
  And even with tab completion that path shows why only a masochist with OCD thinks paths that long or deep are needed. People who name their folders "Documents and images from the conference in August with CEO" deserve what they get. Although 260 characters does seem like the Excel team think more like me than the rest of (more reasonable) MS.
shaggyfrog 13y ago
And TFS can't handle path lengths longer than 260 characters. I don't want to hear the BS about MAX_PATH. These are really annoying customer-facing flaws that scream "amateur hour".
- InclinedPlane 13y ago
  Yup. All due to a choice someone made when deciding how to wrap the win32 file system APIs for dot-net. Also, if you think that's bad, how about this. The TFS build system schedules builds on agent machines using a time format of UTC time of day. Seems fine except for that it is utterly broken in the context of daylight saving time. If you schedule builds that you want to run at a particular local time of day, which almost everyone does as it's an exceedingly common use case, then the actual time of day that build runs will be determined by whether or not the build definition was last saved during the current DST period. For example, if you have a bunch of build definitions and daylight savings time had just ended then builds could run either on time or an hour early.
hiharryhere 13y ago
It's also problematic for enterprises trying to roll out sharepoint. Site addresses tend to be pretty verbose so I can't see that playing particularly nicely given this limitation. Extra points also for the super helpful error messages it throws.
Syssiphus 13y ago
Can't load them either, I guess. When I tried to open an Excel file directly from Sparrow I would get a "path longer than xxx" message. Saving it to ~/Downloads and then opening it worked just fine.
thejosh 13y ago
Neither can winrar, or was that fixed?
deletes 13y ago
When i first hard coded MAX_PATH in my program i though the length was reasonable. Now i think 1024 would be better as a really large file name does happen sometimes. Apple has a limit of 1024 apparently( correct me if I'm wrong ) Solution by microsoft: http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-path...
- gilgoomesh 13y ago
  Setting an arbitrary limit is now and will always be the wrong thing to do in API design. MAX_PATH is one of the most persistent reminders of this problem. Neither 260 chars on Windows nor 1024 chars on the Mac is an actual limit of the filesystem. Both Windows NTFS/FAT32 and Mac HFS+ can actually support thousands of nested folders. But the "MAX_PATH" concept persists and a large number of programs will fail mysteriously when the limit is reached. Even though the filesystem supports vastly more, we are stuck with operating systems that encourage programmers to needlessly limit things. And there's never been a serious push to improve the situation. Long paths aren't a serious alternative since they're not supported by many common Windows APIs (plus, users get confused when \\?\ appears in front of everything). It's completely insane.
  - simias 13y ago
    I think you can blame C's poor string processing functions for that. Every time I have to deal with paths in C I prefer to allocate a static "MAX_PATH" buffer than dealing with dynamic memory allocation and string concatenation (did glibc finally include strlcat or will it take an other decade?). Or better yet, I'd prefer to use a third party lib for that, but I don't know anything small and simple for the command line.
  - asveikau 13y ago
    The \\?\ thing is a weird hack. There are other side-effects of \\?\, for example the system will stop removing trailing spaces and dots from path elements. So you could have a filename that fits well within the limit of MAX_PATH but is inaccessible without \\?\ - just end it with a dot or a space. It's not even always MAX_PATH directly that decides when you need \\?\. IIRC for a directory you must fit within MAX_PATH minus the length of a slash and an 8.3 filename. There are other limits, for example by the time a create gets to the NT APIs the path must fit in a UNICODE_STRING structure which has a maximum length of 0xffff/sizeof(WCHAR). Once I was curious about probing the limits and I created an absolute path that was longer than this limit. I did it with something like this cmd script: mkdir a :top ren a a.tmp mkdir a move a.tmp a\ goto :top Sure enough I was able to create a dir that would stump just about anyone's recursive-directory-delete code. To delete it on my own filesystem I wrote a similar rename-loop to unravel it. If you ever want to play a prank on a Windows programmer who recursively enters directories, show them this.
kfk 13y ago
Let me rant on something here. I work in finance, Excel is my everyday. We do a lot of manual monkey work (copy pasting stuff around a lot), when we "automate", we use the adamant (can't find a better word) VBA. Now, you see how not helpful is this error message? Ok, try that when you are writing a macro in VBA. You literally start regretting the day you were born. Nothing beats Python stack traces...
- web007 13y ago
  From that article, something I haven't seen before: To verify the error message that you receive in Excel 2007, press Ctrl+Shift+I. The following number is displayed in the lower-right corner of this error message dialog box: 100202 It's no stack trace, but should be helpful in searching for proper error codes vs generic text.
  - kfk 13y ago
    Except I am on Excel 2003. The company is slowly moving to 201x although (can't remember the version, the email subject was "digital toolbox" and thus I directly deleted it).
    - roel_v 13y ago
      So do you work with a 2003 version of Python?
      - rsynnott 13y ago
        Python 2.3 still had stack traces.
    - kfk 13y ago
      Nice try. Not my choice to work with Excel 2003 although. Also, I hate the ribbon interface.
blahbap 13y ago
This limitation is obviously put in place to make it easier for the NSA to index your documents
jefffoster 13y ago
The msdn article [1] is a great reference on the strangeness of the Windows path naming conventions. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
patrikr 13y ago
Excel 2007.
- glennos 13y ago
  Not just 2007 from what I can see and given the last update was before Excel 2013 was released, it could be affected too. Do you use 2013? --From the article-- Article ID: 213983 - Last Review: September 18, 2011 - Revision: 6.0 APPLIES TO Microsoft Office Excel 2007 Microsoft Excel 2002 Standard Edition Microsoft Excel 2000 Standard Edition Microsoft Excel 2010
Clorith 13y ago
This gets even worse when mixed in with emails, I recently bumped heads with the naming limitations as the naming of invoices exceeded the limits and rendered the excel file useless (it "existed", it would just error if you tried opening it). File name limitation in 75 characters, so now my system renames the file when sending them by email to just the invoiced clients name, and retains the properly formatted one in the folder structure (It's a very detailed one following a "<course code>-<course name> <course date from and to> <student name> - <billable company>.xsl" pattern as it revolves around certifications and needs to follow certain regulations, and obviously exceeds 75 characters with ease)
CrLf 13y ago
No surprise here. Long path names have always been a pain on Windows, from not being able to open files to not being able to restore previous versions, backups, etc. Hitting these limits is very common on file servers.
jheriko 13y ago
does this apply to 2013? it is a rank amateur quality of mistake... and has been for quite a long time before 2007, since we lost the constraints on paths in early windows/dos land with Windows 95 I think...
mydpy 13y ago
From their page, I offer a suggestion: Things to Try: Increase the maximum path length. Jeez.
jweather 13y ago
It also can't open two documents with the same filename in different directories, which comes up a lot more often in my experience...

54 points by glennos 13y ago

Patrick_Devine 13y ago

Ah.. the old 218 characters in your path problem! Because of course!

tanordheim 13y ago
Visual Studio (at least 2010 and 2012) also has this problem, actually. If the path (including filename) to your solution file is more than 218 characters, it refuses to work with it. Welcome to 1995!
kristopolous 13y ago
It's MAX_PATH in Windows (== 260. There's a 32K Unicode-equivalent limit[1]). In Linux it's PATH_MAX, which is (very likely) 4096. That's a bigger number than 260, sure; but it's still a discrete one; instead of, say, ∞. --- [1] 'To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".' http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
- homeomorphic 13y ago
  You mean finite, not discrete :-)
- thristian 13y ago
  For reference, the GNU Hurd kernel was designed to avoid fixed limits like PATH_MAX. As a result, they have reaped endless compatibility issues with software that assumes there will be some specific fixed limit: https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html https://www.gnu.org/software/hurd/community/gsoc/project_ide...
  - yk 13y ago
    And another proof that GNU Hurd is superior to every existing OS.
sgift 13y ago
MAX_PATH, bane of my existence. I cannot count the times a customer did not find a document in search because Windows decided to throw this limit in our faces. It can pop up at the weirdest places ...
starky 13y ago
I'm pretty sure I said this exact same thing when my boss finally figured out that this issue was causing a script we use to fail on the BOMs I was trying to release. It took an embarrassing amount of time for a few engineers to figure that one out.
randuser 13y ago
My favorite experience with it was trying to deal with a zip file of "C:\Documents and Settings\" from an old computer that happened to contain multiple files whose paths were 255 characters long or so. You couldn't unzip it in a subdirectory of "C:\" because one of the resulting paths would be too long and cause the built-in zip program to crash/fail entirely. Using 7zip was the eventual solution. On a related topic, do you know how difficult it is to search for files whose path are above a certain length on a fresh/default Windows setup? I eventually resorted to installing Python on it just to write a script to do it.

cstrat 13y ago

C:\not\sure\about\the\rest\of\you\but\i\needed\to\see\how\long\that\is\to\fully\understand\the\implications\of\this\seemingly\arbitrary\limitation\-\to\give\this\some\context\this\path\is\two\hundred\and\18\characters\

gilgoomesh 13y ago
When the names mean nothing, it's harder to gauge. Here's a believable directory structure that might lead to the problem: C:\Users\reasonableusername\Documents\Work\CompuGlobalHyperMegaNet\Non-Project Documents\Administrative\Business Contracts\Fiscal 2013\First Quarter\February\Week Two\TPS Reports Cover Sheet And Memos Template - 3.xls
- glennos 13y ago
  Yep, that's the sort of project path structure which was causing me grief. Excel then gave me a warning with a list of 6 possible issues, none of which mentioned the 218 limit.
- pyoung 13y ago
  Yeah, I have seen it first hand. Admittedly, there was some redundancy and some excess in the folder names, but it was for a relatively large project that was organized with fairly deep levels of sub-projects and tasks. If you happened to be working on one of the sub-projects that had a longer, more verbose title, you would run into this issue.
  - agumonkey 13y ago
    Social implications of a size limit can be quite large. Non tech saavy team forced to restart work (half of them will lose the file if saved in a temporary location) after waiting for someone to explain them this additional rule.
lifeisstillgood 13y ago
And even with tab completion that path shows why only a masochist with OCD thinks paths that long or deep are needed. People who name their folders "Documents and images from the conference in August with CEO" deserve what they get. Although 260 characters does seem like the Excel team think more like me than the rest of (more reasonable) MS.

shaggyfrog 13y ago

And TFS can't handle path lengths longer than 260 characters. I don't want to hear the BS about MAX_PATH. These are really annoying customer-facing flaws that scream "amateur hour".

InclinedPlane 13y ago
Yup. All due to a choice someone made when deciding how to wrap the win32 file system APIs for dot-net. Also, if you think that's bad, how about this. The TFS build system schedules builds on agent machines using a time format of UTC time of day. Seems fine except for that it is utterly broken in the context of daylight saving time. If you schedule builds that you want to run at a particular local time of day, which almost everyone does as it's an exceedingly common use case, then the actual time of day that build runs will be determined by whether or not the build definition was last saved during the current DST period. For example, if you have a bunch of build definitions and daylight savings time had just ended then builds could run either on time or an hour early.

hiharryhere 13y ago

It's also problematic for enterprises trying to roll out sharepoint. Site addresses tend to be pretty verbose so I can't see that playing particularly nicely given this limitation. Extra points also for the super helpful error messages it throws.

Syssiphus 13y ago

Can't load them either, I guess. When I tried to open an Excel file directly from Sparrow I would get a "path longer than xxx" message. Saving it to ~/Downloads and then opening it worked just fine.

thejosh 13y ago

Neither can winrar, or was that fixed?

deletes 13y ago

When i first hard coded MAX_PATH in my program i though the length was reasonable. Now i think 1024 would be better as a really large file name does happen sometimes. Apple has a limit of 1024 apparently( correct me if I'm wrong ) Solution by microsoft: http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-path...

gilgoomesh 13y ago
Setting an arbitrary limit is now and will always be the wrong thing to do in API design. MAX_PATH is one of the most persistent reminders of this problem. Neither 260 chars on Windows nor 1024 chars on the Mac is an actual limit of the filesystem. Both Windows NTFS/FAT32 and Mac HFS+ can actually support thousands of nested folders. But the "MAX_PATH" concept persists and a large number of programs will fail mysteriously when the limit is reached. Even though the filesystem supports vastly more, we are stuck with operating systems that encourage programmers to needlessly limit things. And there's never been a serious push to improve the situation. Long paths aren't a serious alternative since they're not supported by many common Windows APIs (plus, users get confused when \\?\ appears in front of everything). It's completely insane.
- simias 13y ago
  I think you can blame C's poor string processing functions for that. Every time I have to deal with paths in C I prefer to allocate a static "MAX_PATH" buffer than dealing with dynamic memory allocation and string concatenation (did glibc finally include strlcat or will it take an other decade?). Or better yet, I'd prefer to use a third party lib for that, but I don't know anything small and simple for the command line.
- asveikau 13y ago
  The \\?\ thing is a weird hack. There are other side-effects of \\?\, for example the system will stop removing trailing spaces and dots from path elements. So you could have a filename that fits well within the limit of MAX_PATH but is inaccessible without \\?\ - just end it with a dot or a space. It's not even always MAX_PATH directly that decides when you need \\?\. IIRC for a directory you must fit within MAX_PATH minus the length of a slash and an 8.3 filename. There are other limits, for example by the time a create gets to the NT APIs the path must fit in a UNICODE_STRING structure which has a maximum length of 0xffff/sizeof(WCHAR). Once I was curious about probing the limits and I created an absolute path that was longer than this limit. I did it with something like this cmd script: mkdir a :top ren a a.tmp mkdir a move a.tmp a\ goto :top Sure enough I was able to create a dir that would stump just about anyone's recursive-directory-delete code. To delete it on my own filesystem I wrote a similar rename-loop to unravel it. If you ever want to play a prank on a Windows programmer who recursively enters directories, show them this.

kfk 13y ago

Let me rant on something here. I work in finance, Excel is my everyday. We do a lot of manual monkey work (copy pasting stuff around a lot), when we "automate", we use the adamant (can't find a better word) VBA. Now, you see how not helpful is this error message? Ok, try that when you are writing a macro in VBA. You literally start regretting the day you were born. Nothing beats Python stack traces...

web007 13y ago
From that article, something I haven't seen before: To verify the error message that you receive in Excel 2007, press Ctrl+Shift+I. The following number is displayed in the lower-right corner of this error message dialog box: 100202 It's no stack trace, but should be helpful in searching for proper error codes vs generic text.
- kfk 13y ago
  Except I am on Excel 2003. The company is slowly moving to 201x although (can't remember the version, the email subject was "digital toolbox" and thus I directly deleted it).
  - roel_v 13y ago
    So do you work with a 2003 version of Python?
    - rsynnott 13y ago
      Python 2.3 still had stack traces.
  - kfk 13y ago
    Nice try. Not my choice to work with Excel 2003 although. Also, I hate the ribbon interface.

blahbap 13y ago

This limitation is obviously put in place to make it easier for the NSA to index your documents

jefffoster 13y ago

The msdn article [1] is a great reference on the strangeness of the Windows path naming conventions. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

patrikr 13y ago

Excel 2007.

glennos 13y ago
Not just 2007 from what I can see and given the last update was before Excel 2013 was released, it could be affected too. Do you use 2013? --From the article-- Article ID: 213983 - Last Review: September 18, 2011 - Revision: 6.0 APPLIES TO Microsoft Office Excel 2007 Microsoft Excel 2002 Standard Edition Microsoft Excel 2000 Standard Edition Microsoft Excel 2010

Clorith 13y ago

This gets even worse when mixed in with emails, I recently bumped heads with the naming limitations as the naming of invoices exceeded the limits and rendered the excel file useless (it "existed", it would just error if you tried opening it). File name limitation in 75 characters, so now my system renames the file when sending them by email to just the invoiced clients name, and retains the properly formatted one in the folder structure (It's a very detailed one following a "<course code>-<course name> <course date from and to> <student name> - <billable company>.xsl" pattern as it revolves around certifications and needs to follow certain regulations, and obviously exceeds 75 characters with ease)

CrLf 13y ago

No surprise here. Long path names have always been a pain on Windows, from not being able to open files to not being able to restore previous versions, backups, etc. Hitting these limits is very common on file servers.

jheriko 13y ago

does this apply to 2013? it is a rank amateur quality of mistake... and has been for quite a long time before 2007, since we lost the constraints on paths in early windows/dos land with Windows 95 I think...

mydpy 13y ago

From their page, I offer a suggestion: Things to Try: Increase the maximum path length. Jeez.

jweather 13y ago

It also can't open two documents with the same filename in different directories, which comes up a lot more often in my experience...