Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excel can't save to paths over 218 characters

support.microsoft.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Excel can't save to paths over 218 characters

#31

Post by simias »

gilgoomesh wrote: post #24
deletes wrote: post #17

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

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 mysteri…

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.

Re: Excel can't save to paths over 218 characters

#32

Post by 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 "- - .xsl" pattern as it revolves around certifications and needs to follow certain regulations, and obviously exceeds 75 characters with ease)

Re: Excel can't save to paths over 218 characters

#33

Post by jsankey »

lifeisstillgood wrote: post #10
cstrat wrote: post #5

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\

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.

You're assuming all paths are created and consumed by humans. Automated processes could easily generate and work with long paths for perfectly-valid reasons. A limit this low causes grief for people that "deserve" better.

Re: Excel can't save to paths over 218 characters

#34

Post by roel_v »

kfk wrote: post #27
web007 wrote: post #22

Earlier quoted context omitted.

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.

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

So do you work with a 2003 version of Python?

Re: Excel can't save to paths over 218 characters

#35

Post by kfk »

kfk wrote: post #27
web007 wrote: post #22

Earlier quoted context omitted.

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.

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

Nice try. Not my choice to work with Excel 2003 although. Also, I hate the ribbon interface.

Re: Excel can't save to paths over 218 characters

#36

Post by yk »

thristian wrote: post #19
kristopolous wrote: post #4

Earlier quoted context omitted.

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

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

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

Re: Excel can't save to paths over 218 characters

#37

Post by InclinedPlane »

shaggyfrog wrote: post #6

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

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.

Re: Excel can't save to paths over 218 characters

#38

Post by asveikau »

gilgoomesh wrote: post #24
deletes wrote: post #17

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

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 mysteri…

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.

Re: Excel can't save to paths over 218 characters

#39

Post by glennos »

patrikr wrote: post #28

Excel 2007 .

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

Re: Excel can't save to paths over 218 characters

#40

Post by lewispollard »

jsankey wrote: post #33
lifeisstillgood wrote: post #10

Earlier quoted context omitted.

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.

You're assuming all paths are created and consumed by humans. Automated processes could easily generate and work with long paths for perfectly-valid reasons. A limit this low causes grief for people that "deserve" better.

Exactly, recently had some visual studio build problems with a large repository and local node modules going over the file path limit.
Post reply on HN