8
JS96
2y

Why, in 2023, do we still have a path length limit in Windows?

I know it's not that trivial finding a good soution, but at least if I managed to get a .zip which I can't extract in that directory because of a few files with a too long file name, let me know in advance (and not during the extraction) and maybe (amazing idea) let me know how many steps I have to go back in the directories tree to make it work…

Comments
  • 4
    This becomes a real issue once you start to work with files in the OneDrive directory (which root path is already long by design).
  • 7
    At my work i have to keep my projects ideally in root folder of my disk. Projects are so deep and with long naming that I get to this problem pretty often. Annoying AF.
    I don't give a flying fuck what's the reason behind it, just make it work ffs, Microsoft?!
    This path thing, and the "Excel file with the same name is already open" problem are probably the two MShit things I just can not wrap my head around.
  • 2
    Because you don't know how to enable long paths in windows. 🤷‍♂️

    Not that, that's a great solution over all either 😅
  • 1
    @C0D4 I heard about that. Do you know what the downsides are? If there aren’t any downsides, why isn’t it the default?
  • 1
    Ok I can think of one reason myself:

    Some old software might break if you give it a long path name because it assumes that this long name can’t exist.
    And MS doesn’t want to break compatibility with it.
  • 3
    @Lensflare Yep, backward compatibility.

    But I'm pretty sure there is at least one real solution to this problem (not just by removing the limit and making the legacy apps crash).

    I don't know, like creating virtual paths for too long file names, returning still max 260 chars to the application, and handling everything by the OS API.
  • 0
    Funny, only 1 months has passed in 2023 and still complaining about a problem that already has been solved in Windows 10 version 1607.

    It is an opt-in option...

    But I guess you didn't read the manual.
  • 3
    @Grumm I'm glad that you and the other MS employee who wrote it, read the manual.

    I develop enough to know that a "opt-in" solution is not a solution, because 99.99% of the affected users will never know it has been fixed.

    A solution is when you fix something for everyone by default, otherwise is just a workaround.
  • 7
    Microsoft wants to make sure that the MS-DOS powered COBOL code that powers our critical internet, banking, and military infrastructure won't crash when you give it a path with length 261 characters.

    (It turns out the reason for 260 is to give you room for the drive letter and a null terminator with 256 characters in between)
  • 5
    @JS96

    No. There isn't.

    https://learn.microsoft.com/en-us/...

    Or more specific:

    https://learn.microsoft.com/en-us/...

    The limitation is *inside* the API.

    MS doesn't break the API.

    What the registry setting does is upping in certain APIs the limit - not all.

    The problem with Windows is exactly that: An API shall never be changed - which is why only *certain* APIs can deal with the new limit, while older ones won't work.

    Windows might let you run games from 1990 plus - but the price is that there can be zero change.

    E.g. NetBIOS still exists in Windows - it's from 1983...

    Everything new - even sth like your mentioned real solutions - would have to be implemented, which means changing the APIs... Which is a no no.

    It's the reason why I think Windows is kinda self destructing - the amount of crap they don't wanna remove is insane.
  • 0
    @JS96 Like @InstrusionCM said, it isn't really a fix.

    They made it an option if you need more than 256 characters.

    With normal usage of a PC, that limit should really not be an issue. Unless you are making some big folder structure with only Guid names. But that may be a very crazy thing to do...

    I prefer opt-in options. Than options that I don't need are turned back on with every major update...
  • 1
    It’s sad because the same applies to so many other aspects of software and programming.

    Either break compatibility or deal with broken shit for eternity.

    I always prefer the breaking compatibility.

    In general, I think that MS tends to be on the compatibility side and Apple on the breaking side. I see it in their products, operating systems and programming languages.
Add Comment