
Excel can't save to paths over 218 characters - glennos
http://support.microsoft.com/kb/213983
======
cstrat
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\

~~~
lifeisstillgood
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.

~~~
gilgoomesh
> only a masochist with OCD thinks paths that long or deep are needed

I'm surprised you can't imagine working on a path that deep. Path arrangements
are frequently thrust upon you in work environments and if you have a lot of
work (or a lot of people sharing the same folder hierarchy), you may need a
deep path structure to keep it organized. Attacking people as "masochists"
because their paths are difficult to type seems unfair.

As for your example though, Windows usually shortens path components longer
than 8 characters as the path gets longer (so "Program Files" becomes
"PROGRA~1") so long single components aren't as problematic as many shorter
components.

~~~
johnchristopher
I am pretty sure it's more for historical reasons than a solution from MS for
long filenames on win32. It's due to the application writing to the file-
system, not the OS.

Earlier DOS FS (and others) were sometimes limited to 8 characters + 3 for
extension and Windows just used to shorten filenames when writing to those FS.
But to these days it still causes some problems for legacy software and you
might see some PROGRA~1 hanging around but it's not from the OS, it's from the
application (or its old out-date API for FS access) doing the shortening to
fit the long filename it was given into an 8 characters word it thinks the FS
can handle.

Windows's file explorer or file picker doesn't shorten path or filenames when
downloading long filename from the web for instance (via Firefox or IE).

------
deletes
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-
path...](http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-
part-1-of-3-kim-hamilton.aspx)

~~~
gilgoomesh
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.

~~~
asveikau
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
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
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
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
So do you work with a 2003 version of Python?

~~~
rsynnott
Python 2.3 still had stack traces.

------
shaggyfrog
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
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
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.

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

~~~
kristopolous
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/aa36...](http://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

~~~
thristian
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_ide...](https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html)

~~~
yk
And another proof that GNU Hurd is superior to every existing OS.

------
jefffoster
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/aa36...](http://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

------
Clorith
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)

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

------
Syssiphus
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.

------
CrLf
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.

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

Jeez.

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

------
jheriko
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...

------
thejosh
Neither can winrar, or was that fixed?

------
patrikr
Excel _2007_.

~~~
glennos
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

