6 ms·

The irony of this is half of Windows is STILL utterly BROKEN with respect to path lengths since LFN was introduced in the Win32 API and it shoots you almost eve

The irony of this is half of Windows is STILL utterly BROKEN with respect to path lengths since LFN was introduced in the Win32 API and it shoots you almost every day if you have to work with any deep directory hierarchies. There are so many rules it's unfunny: http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).as...

WayneDB 15y ago
Broken is a point of view. Backwards compatibility is important to Microsoft.
- pointyhat 15y ago
  They broke it on day one. Basically we are stuck with a bad decision. It's a Win32 subsystem specific problem. Both NT and NTFS do not have this issue internally. It's not backwards compatibility - it's just a turd.
  - archangel_one 15y ago
    It is backwards compatibility, because there are a fantastic number of programs out there that simply allocate a MAX_PATH sized buffer and assume that a single file path has to fit into it. If MS simply changed things so that paths of 500 characters could be returned all those programs would fail.
    - rbanffy 15y ago
      > all those programs would fail. And, hopefully, be rewritten. Or, you could have a new set of API calls without this limitation. This new API could also receive a version argument, so that calls to its present version would return present-style data, even if the then-current implementation were much smarter. It's so obvious, in fact, I wouldn't be surprised if they already did it.
      - ephemient 15y ago
        As said above, it's only Win32 that's broken. NT filenames (e.g. \\?\...) aren't limited by MAX_PATH.
        rbanffy 15y ago
        How well documented is the NT kernel APIs? I remember reading the documentation is a little sparse (no first-hand experience)
        btn 15y ago
        These aren't kernel APIs. In most cases, you can simply call the Unicode version of the same functions and prepend "\\?\".
InclinedPlane 15y ago
Been there, done that. People think it's awesome to create a bunch of long, nested directory names, until the fully qualified file name becomes too long for max path and automation starts breaking.
- pointyhat 15y ago
  Spot on. The problem for me is that in some software (Visual Studio) it breaks and other software (MSBuild) it works so you get inconsistent issues. In my case, it dies when building VS solutions (vs.net is win32) on disk but not using MSBuild (win64 platform). Basically software dev breaks something by creating long file name (which if you ask me is fine) yet the integration tests succeed.
gcv 15y ago
Indeed! Try writing a Windows file system driver sometime; I hear it's truly a lovely experience. The other irony is that the HP48 graphing calculator, originally introduced in 1990, had a user-facing filesystem with full support for long file and directory names. I'd be curious to learn what possessed the people responsible for DOS to have ever shipped a system with the insane 8.3 restriction. Even ancient Unix filesystems (early 1970s vintage) supported far more reasonable 14-character filenames.
- pointyhat 15y ago
  NT API is fine - it's Win32 subsystem that is broken.
- rbanffy 15y ago
  > I'd be curious to learn what possessed the people responsible for DOS to have ever shipped a system with the insane 8.3 restriction CP/M inspired them. PC-DOS (Q-DOS, really) was more or less a rip-off of DR's CP/M-80. It's possible to give "ease of porting CP/M-80 programs to PC-DOS" as an excuse for that. At that time, short file names were not a big issue, as CP/M filesystems were rather small (5-megabyte hard disks were very expensive at the time) and hierarchical filesystems were outside the realm of microcomputers. PC-DOS didn't introduce directories until version 2. BTW, the Apple II DOS (all versions) had filenames of up to (IIRC) 33 chars, case-sensitive and with one byte to indicate the file type with a flat hierarchy. ProDOS has 16-char filenames with a hierarchical structure.

WayneDB 15y ago

Broken is a point of view. Backwards compatibility is important to Microsoft.

pointyhat 15y ago
They broke it on day one. Basically we are stuck with a bad decision. It's a Win32 subsystem specific problem. Both NT and NTFS do not have this issue internally. It's not backwards compatibility - it's just a turd.
- archangel_one 15y ago
  It is backwards compatibility, because there are a fantastic number of programs out there that simply allocate a MAX_PATH sized buffer and assume that a single file path has to fit into it. If MS simply changed things so that paths of 500 characters could be returned all those programs would fail.
  - rbanffy 15y ago
    > all those programs would fail. And, hopefully, be rewritten. Or, you could have a new set of API calls without this limitation. This new API could also receive a version argument, so that calls to its present version would return present-style data, even if the then-current implementation were much smarter. It's so obvious, in fact, I wouldn't be surprised if they already did it.
    - ephemient 15y ago
      As said above, it's only Win32 that's broken. NT filenames (e.g. \\?\...) aren't limited by MAX_PATH.
      - rbanffy 15y ago
        How well documented is the NT kernel APIs? I remember reading the documentation is a little sparse (no first-hand experience)
        btn 15y ago
        These aren't kernel APIs. In most cases, you can simply call the Unicode version of the same functions and prepend "\\?\".

InclinedPlane 15y ago

Been there, done that. People think it's awesome to create a bunch of long, nested directory names, until the fully qualified file name becomes too long for max path and automation starts breaking.

pointyhat 15y ago
Spot on. The problem for me is that in some software (Visual Studio) it breaks and other software (MSBuild) it works so you get inconsistent issues. In my case, it dies when building VS solutions (vs.net is win32) on disk but not using MSBuild (win64 platform). Basically software dev breaks something by creating long file name (which if you ask me is fine) yet the integration tests succeed.

gcv 15y ago

Indeed! Try writing a Windows file system driver sometime; I hear it's truly a lovely experience. The other irony is that the HP48 graphing calculator, originally introduced in 1990, had a user-facing filesystem with full support for long file and directory names. I'd be curious to learn what possessed the people responsible for DOS to have ever shipped a system with the insane 8.3 restriction. Even ancient Unix filesystems (early 1970s vintage) supported far more reasonable 14-character filenames.

pointyhat 15y ago
NT API is fine - it's Win32 subsystem that is broken.
rbanffy 15y ago
> I'd be curious to learn what possessed the people responsible for DOS to have ever shipped a system with the insane 8.3 restriction CP/M inspired them. PC-DOS (Q-DOS, really) was more or less a rip-off of DR's CP/M-80. It's possible to give "ease of porting CP/M-80 programs to PC-DOS" as an excuse for that. At that time, short file names were not a big issue, as CP/M filesystems were rather small (5-megabyte hard disks were very expensive at the time) and hierarchical filesystems were outside the realm of microcomputers. PC-DOS didn't introduce directories until version 2. BTW, the Apple II DOS (all versions) had filenames of up to (IIRC) 33 chars, case-sensitive and with one byte to indicate the file type with a flat hierarchy. ProDOS has 16-char filenames with a hierarchical structure.