Cool! Can the "NT paths" be used directly on Windows? As far as I know the ordinary Win32/NTFS system doesn't even have symlinks and this feels quite a handicap.
Note that this is behind a "developper flag", i.e. it needs elevation if you have not checked "developper mode" in the W10 parameters. (I guess they don't want the cost of supporting ordinary people building circular dependencies)
For example rust has support[0] for the magical file path prefixes[1] that can be used to escape path length restrictions, reserved identifiers and some other limitations. This is used by default whenever you normalize a part, which means it has fewer restrictions than windows explorer has by default.
[0] https://doc.rust-lang.org/std/path/enum.Prefix.html [1] https://docs.microsoft.com/en-us/windows/desktop/fileio/nami...
So it is relatively easy to add hooks of your own that get called as if they were file reads; NTFS calls these "Reparse Points". Linux would do this with named pipes.
I am just a user of these things, haven't dug into any implementation details recently, but I guess that the stacks to support these features in Linux and Windows each have their cache etc design decisions that have led to current state of filesystem performance under typical use-cases these days.
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.
It happens to be not enough just so damn often.
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\
Name it filepathlimit/filepathlimit.epub or something. Done. You can actually read that. Now if you want the prose, open the damn file. Or use the file explorer which might already show you a more complete title based on the file metadata.
And don't do that "C:\Documents and Settings\John Doe\My Documents\My Projects\Books\". There is no point in storing your things deep in a thousand rabbit holes. It's overzealous hierarchy fetishism. There is no point in creating unreadable paths that wrap around lines like wild. Use D:\Books or something. Or D:\John\Books if you must. Use basic common sense.
I don't do, but I work with other people's stuff and almost every non-geek does that.
> And don't do that "C:\Documents and Settings\John Doe\My Documents\My Projects\Books\". There is no point in storing your things deep in a thousand rabbit holes
That's the standard way Windows users are meant to store their data (although I don't). What is "\home\jdoe\" on Linux is "C:\Documents and Settings\John Doe\My Documents\" on Windows ("C:\Documents and Settings\John Doe\" actually but not from an ordinary user point of view).
> It's overzealous hierarchy fetishism.
I actually find it sad we are still using hierarchies for that when we could be just using tags and semantic attributes instead (semantically a document file doesn't even need a "file name", the actual document title stored as an atribute or as a record within the file is enough and actually better). Apparently it seems ordinary people are more comfortable with the folder metaphor and hierarchies so WinFS was cancelled and 3rd party tagging and semantic desktop systems are little know.
no, it's 260 characters regardless of whether you're using char or wchar_t
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.
It just seems node.js is broken.
Nested dependencies have negative effects on all of those. They encourage uncontrolled addition of modules, and even addition of modules in multiple versions. They lead to wrong "isolationist" thinking.
In other words, they do not manage complexity but produce unneeded complexity.