Comment by jstimpfle
7 years ago
I'm not a super expert but I think that is the case and you even need them if you want to use some advanced features like paths that are longer than MAX_PATH or these virtual mount kinds of things.
But IMO it's ugly as hell and just begging for compatibility problems. So don't go there, at least not to get super long paths. 260 bytes should be enough for anybody.
> 260 bytes should be enough for anybody
It happens to be not enough just so damn often.
How did you manage? I've never hit the limit in like 20 years. Maybe 260 bytes means only 130 2-byte characters (I don't even know) and that I might find a little restrictive maybe. In any case I'm tempted to say, just fix your damn paths (if possible). I guess at 80 characters it starts to get unreadable anyway.
Of course I have only encountered filenames this long a couple times but as for full path like C:\something\something this is very easy.
E.g. "How did you manage? I've never hit the limit in like 20 years." is 63 characters and it still looks like a reasonable title for a book. You may have written or downloaded a book and stored it in a folder named this way in multiple formats (i.e. PDF, EPUB etc) and this can already make something like "C:\Documents and Settings\John Doe\My Documents\My Projects\Books\How did you manage - I've never hit the limit in like 20 years\How did you manage - I've never hit the limit in like 20 years.epub" and this already is 199 characters. Just 60 characters left and 60 characters is as short as "C:\Documents and Settings\John Doe\My Documents", and you might in fact have your book file named a longer way like "John Doe - How did you manage? I've never hit the limit in like 20 years. 2nd edition draft". This is a bit clumsy example but it demonstrates how easily reachable the limit actually is in the real life.
This actually forced me to store my data in c:\a\b\c... (where a, b, and c actually were 1-4-letter acronyms) instead of C:\Documents and Settings\John Doe\My Documents\
2 replies →
It is actually surprisingly common to hit the max path length with build systems. Why?
You're building a project. Your source code is under C:\Users\twenty-ish character username\Documents\Projects\. The project name is a released build which got extracted to something network-configurator-1.4.5, which builds into a build directory underneath that. That's up to 80 characters right there, only 180 remaining.
If you have any process that starts doing something like "place the artifacts needed to build <result>.foo in result/" (say, cmake), and throw in some hierarchy nesting, you can chew up 180 characters remarkably quickly. Something like node.js produces this monstrosity of a path name:
./node_modules/istanbul-harmony/node_modules/handlebars/node_modules/uglify-js/node_modules/source-map/test/source-map/test-source-map-consumer.js
Names that seem reasonable within the context of their folder may turn out to be highly redundant in the context of the entire pathname--but many people would rather prefer to have readable names at each level of the folder hierarchy, which makes it hard to make full pathnames reasonable. Sometimes, these names are required by means of a language implementation or other build system that is uncontrollable by you.
4 replies →
>Maybe 260 bytes means only 130 2-byte characters
no, it's 260 characters regardless of whether you're using char or wchar_t