3 ms·

https://msdn.microsoft.com/de-de/library/windows/desktop/bb773571(v=vs.85).aspx https://msdn.microsoft.com/de-de/library/windows/desktop/bb7...

robocat 9y ago
Exactly my point - that function doesn't deal with modern windows. MAX_PATH is 260 characters. Yet Windows now supports longer paths (\\?\ prefix). So I presume there is another Windows function to combine long path names (and maybe canonicalise Unicode better).
- jstimpfle 9y ago
  > Yet Windows now supports longer paths (\\?\ prefix). I know. And this is the attitude that leads to complex software. It's a self-fulfilling prophecy: "I can't do it on my own since the problem is so complex". In which case the problem does get complex. I recommend not wasting time supporting this crazy feature (unless you are writing infrastructure code for tools and you're required to - in which case I'm sorry). 260 character paths are more than enough for any project. And I certainly recommend against using the crazy abstractions from Boost::filesystem. (Personally I think it's an unfortunate example. I'd prefer to avoid paths from the start, since nobody understands the semantics of hierarchical filesystems. Alas, typically you need to deal with them to some degree).
  - robocat 9y ago
    It is not a crazy feature. It is a necessary feature for many development environments originally written for Unix (e.g. nodejs), because Unix file systems usually don't have such a low character limit. Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) Really... You are showing exactly why one uses a library so one doesn't need to care about the "complex" details because one hopes the library does a good job of managing it as well as possible for you (although you still need to know the details to use a library function safely).
    - jstimpfle 9y ago
      > Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) 260 bytes is long. I've never seen a \\?\ path in the wild, and I don't want to. It's a misdesign (well, I'm sure the designer didn't want to design it...). But I'm repeating myself... I can't practically deal with paths longer than, say, 64 characters (can't read them, let alone type them). Fix your paths. And again, this is off-topic. This thread was about not using a crazy third party library, when the authoritative semantics (however insane) are contained in the OS interface.
      - Klathmon 9y ago
        That is such an awful toxic viewpoint to take. "Fix my paths"!? Fix your software! I work from a network share that is about 70 chars long to get to my one project's folder. The beauty of hierarchical file systems is that I can cognitively ignore all the previous paths and just work from there. However when your software doesn't work because "the solution is a misdesign", it's not my path that is wrong, it's your software that is broken and you that are stubbornly refusing to use solutions to well known problems.
        jstimpfle 9y ago
        > 70 chars Still supported by 260-byte filepaths. Asking nevertheless: Why? The path to the network share should be easy to abbreviate. More philosophically: I'm sorry that you can't use file systems because most support only filenames up to 256 bytes. I'm sorry that you can't use the web because most browsers only support URLs up to 2048 bytes. I'm sorry that you can't use a keyboard because they have only 8-bit scancodes. I'm sorry that you can't use the network because frames can only be so big. I'm sorry that you can't watch a movie because a disc fits only so many bytes. It's truly a toxic world.
        Klathmon 9y ago
        >Still supported by 260-byte filepaths. Because now programs that thought "260 is enough" now only have 190 left, and i've seen (and had software not work with) several pieces of software that have more than that. Because the assumption is that this is a solved problem on all OSs, and that 260 is no longer a hard limit. >Asking nevertheless: Why? The path to the network share should be easy to abbreviate. Because that doesn't actually solve the problem. I can abbreviate it on my connection, but not on the server, and if the server is running some poorly written software, it will choke when from my point of view i'm only using 190 characters. As for why, it's segmented by country/company/department/team/name/employeeid/ Then it is my folder, where I have things like clientInformation/[softwarePackage]/[client]/[testFiles|documentation|uniqueArchitecture] Just the example without any real names is over 100 already. I just went and looked, I was being conservative with my 70-character estimate, a few of my folders are over 180 characters long just to the [client] part of my path. Also why abbreviate it when we can write software that can handle that for us? Why should I need to shorten my paths to potentially confusing and misleading names just so some people can ignore solved problems in the name of "complexity". Not to mention that abbreviation isn't really a "solution" (what happens when there are collisions? Now you need a complicated "maintained and interpreted by humans" system to manage it, that's not simpler, that's more complex). I'm honestly not going to respond to the rest, because we both know that those are strawman arguments.

robocat 9y ago

Exactly my point - that function doesn't deal with modern windows. MAX_PATH is 260 characters. Yet Windows now supports longer paths (\\?\ prefix). So I presume there is another Windows function to combine long path names (and maybe canonicalise Unicode better).

jstimpfle 9y ago
> Yet Windows now supports longer paths (\\?\ prefix). I know. And this is the attitude that leads to complex software. It's a self-fulfilling prophecy: "I can't do it on my own since the problem is so complex". In which case the problem does get complex. I recommend not wasting time supporting this crazy feature (unless you are writing infrastructure code for tools and you're required to - in which case I'm sorry). 260 character paths are more than enough for any project. And I certainly recommend against using the crazy abstractions from Boost::filesystem. (Personally I think it's an unfortunate example. I'd prefer to avoid paths from the start, since nobody understands the semantics of hierarchical filesystems. Alas, typically you need to deal with them to some degree).
- robocat 9y ago
  It is not a crazy feature. It is a necessary feature for many development environments originally written for Unix (e.g. nodejs), because Unix file systems usually don't have such a low character limit. Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) Really... You are showing exactly why one uses a library so one doesn't need to care about the "complex" details because one hopes the library does a good job of managing it as well as possible for you (although you still need to know the details to use a library function safely).
  - jstimpfle 9y ago
    > Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) 260 bytes is long. I've never seen a \\?\ path in the wild, and I don't want to. It's a misdesign (well, I'm sure the designer didn't want to design it...). But I'm repeating myself... I can't practically deal with paths longer than, say, 64 characters (can't read them, let alone type them). Fix your paths. And again, this is off-topic. This thread was about not using a crazy third party library, when the authoritative semantics (however insane) are contained in the OS interface.
    - Klathmon 9y ago
      That is such an awful toxic viewpoint to take. "Fix my paths"!? Fix your software! I work from a network share that is about 70 chars long to get to my one project's folder. The beauty of hierarchical file systems is that I can cognitively ignore all the previous paths and just work from there. However when your software doesn't work because "the solution is a misdesign", it's not my path that is wrong, it's your software that is broken and you that are stubbornly refusing to use solutions to well known problems.
      - jstimpfle 9y ago
        > 70 chars Still supported by 260-byte filepaths. Asking nevertheless: Why? The path to the network share should be easy to abbreviate. More philosophically: I'm sorry that you can't use file systems because most support only filenames up to 256 bytes. I'm sorry that you can't use the web because most browsers only support URLs up to 2048 bytes. I'm sorry that you can't use a keyboard because they have only 8-bit scancodes. I'm sorry that you can't use the network because frames can only be so big. I'm sorry that you can't watch a movie because a disc fits only so many bytes. It's truly a toxic world.
        Klathmon 9y ago
        >Still supported by 260-byte filepaths. Because now programs that thought "260 is enough" now only have 190 left, and i've seen (and had software not work with) several pieces of software that have more than that. Because the assumption is that this is a solved problem on all OSs, and that 260 is no longer a hard limit. >Asking nevertheless: Why? The path to the network share should be easy to abbreviate. Because that doesn't actually solve the problem. I can abbreviate it on my connection, but not on the server, and if the server is running some poorly written software, it will choke when from my point of view i'm only using 190 characters. As for why, it's segmented by country/company/department/team/name/employeeid/ Then it is my folder, where I have things like clientInformation/[softwarePackage]/[client]/[testFiles|documentation|uniqueArchitecture] Just the example without any real names is over 100 already. I just went and looked, I was being conservative with my 70-character estimate, a few of my folders are over 180 characters long just to the [client] part of my path. Also why abbreviate it when we can write software that can handle that for us? Why should I need to shorten my paths to potentially confusing and misleading names just so some people can ignore solved problems in the name of "complexity". Not to mention that abbreviation isn't really a "solution" (what happens when there are collisions? Now you need a complicated "maintained and interpreted by humans" system to manage it, that's not simpler, that's more complex). I'm honestly not going to respond to the rest, because we both know that those are strawman arguments.