4 ms·

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 pro

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.
  - jstimpfle 9y ago
    No strawmans in the slightest. Exactly the same kind of very real (and not really solveable) "problems". It's beyond me how far removed from reality these arguments are. You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes), and they could easily be fixed (which would be a win on all non-technical fronts as well), but still you're complaining for no good reason. You clearly lack experience with low-level issues - just imagine what a technical mess it is in Windows to support longer paths (I think there is a concept called "junction points" to support them). Please, can we turn to actual problems?
    - Klathmon 9y ago
      But this is solvable! You are the one claiming it's too complex then refusing to use the well tested solutions... >You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes) but still complaining. Because that's just the path to a folder, that still doesn't contain any data! unpack an archive from a server in one, and suddenly poorly written software is blowing up because someone used a GUID as a folder name, or there is software running there that assumes "why would paths need to be less than 60 characters!?" and nests files into a bunch of folders using the filesystem as a tree of hashes. I think the problem here is that these aren't imagined problems, they are problems I've run into in the past year or so. The difference between this and your strawman arguments is that there are solutions to all of those problems as well, but for some reason you don't see them as superfluous. I don't know why I let myself get roped into a pointless internet argument. "You clearly lack experience with low-level issues"? Man I'd love to see how you determined that from a few comments about file paths...
      - jstimpfle 9y ago
        > I'd love to see how you determined that from a few comments about file paths... It's easy to see from the discussion. If you had ever thought about designing a filesystem or binary network protocol or kernel filesystem API or a C software architecture, you would not be so invested and instead turn to real 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.
- jstimpfle 9y ago
  No strawmans in the slightest. Exactly the same kind of very real (and not really solveable) "problems". It's beyond me how far removed from reality these arguments are. You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes), and they could easily be fixed (which would be a win on all non-technical fronts as well), but still you're complaining for no good reason. You clearly lack experience with low-level issues - just imagine what a technical mess it is in Windows to support longer paths (I think there is a concept called "junction points" to support them). Please, can we turn to actual problems?
  - Klathmon 9y ago
    But this is solvable! You are the one claiming it's too complex then refusing to use the well tested solutions... >You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes) but still complaining. Because that's just the path to a folder, that still doesn't contain any data! unpack an archive from a server in one, and suddenly poorly written software is blowing up because someone used a GUID as a folder name, or there is software running there that assumes "why would paths need to be less than 60 characters!?" and nests files into a bunch of folders using the filesystem as a tree of hashes. I think the problem here is that these aren't imagined problems, they are problems I've run into in the past year or so. The difference between this and your strawman arguments is that there are solutions to all of those problems as well, but for some reason you don't see them as superfluous. I don't know why I let myself get roped into a pointless internet argument. "You clearly lack experience with low-level issues"? Man I'd love to see how you determined that from a few comments about file paths...
    - jstimpfle 9y ago
      > I'd love to see how you determined that from a few comments about file paths... It's easy to see from the discussion. If you had ever thought about designing a filesystem or binary network protocol or kernel filesystem API or a C software architecture, you would not be so invested and instead turn to real problems.