3 ms·
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 sti
by 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.