4 ms·

> paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?

by xfer 6y ago

KiwiJohnno 6y ago
To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem. The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow. There are other, newer Win32 APIs for all of these that don't have that limitation, but apps have to be changed to use them.
- olvy0 6y ago
  You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either. Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think). But, they're only accept file paths this long if those paths begin with the magic sequence \\?\ [0]. So each "normal" path has to be "normalized" to this format in order to be longer than 260 characters. This is a usually a trivial operation of appending this sequence, but it's slightly much complicated than it looks, and also not well known for some reason. I'm not aware of any newer APIs that can natively accept long path names, btw, The Windows Explorer shell, and so the standard Open File dialog used by most application, uses the "non-normalized" form without the magic prefix, and so can't be used to view, delete or create those long paths. So to bring this discussion back to the original post: 7zip is very good to have on your system if only to be used as a viewer for files on those long paths, and in order to delete them, since Windows explorer can't... Incidentally, the other common application which can handle long paths is git for windows. As for the much hyped ability in Windows 10 to enable the support natively : it's still not enabled by default, so you can't count on it being present on user's machines. BTW, I'm using an open source library for dotnet called Zeta Long Path, which does exactly this (appending this magic sequence) and works wonderfully well, even on Windows XP. But you're right that most people who use those APIs directly usually allocate a 260 char array and use it, and if Microsoft would suddenly change the behavior and started returning actual long paths then those applications would blow up. [0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maximum-path-length-limitation https://docs.microsoft.com/en-us/windows/win32/fileio/naming... [1] https://github.com/UweKeim/ZetaLongPaths https://github.com/UweKeim/ZetaLongPaths

> paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?

by xfer 6y ago

> paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?

KiwiJohnno 6y ago

To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem. The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow. There are other, newer Win32 APIs for all of these that don't have that limitation, but apps have to be changed to use them.

olvy0 6y ago
You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either. Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think). But, they're only accept file paths this long if those paths begin with the magic sequence \\?\ [0]. So each "normal" path has to be "normalized" to this format in order to be longer than 260 characters. This is a usually a trivial operation of appending this sequence, but it's slightly much complicated than it looks, and also not well known for some reason. I'm not aware of any newer APIs that can natively accept long path names, btw, The Windows Explorer shell, and so the standard Open File dialog used by most application, uses the "non-normalized" form without the magic prefix, and so can't be used to view, delete or create those long paths. So to bring this discussion back to the original post: 7zip is very good to have on your system if only to be used as a viewer for files on those long paths, and in order to delete them, since Windows explorer can't... Incidentally, the other common application which can handle long paths is git for windows. As for the much hyped ability in Windows 10 to enable the support natively : it's still not enabled by default, so you can't count on it being present on user's machines. BTW, I'm using an open source library for dotnet called Zeta Long Path, which does exactly this (appending this magic sequence) and works wonderfully well, even on Windows XP. But you're right that most people who use those APIs directly usually allocate a 260 char array and use it, and if Microsoft would suddenly change the behavior and started returning actual long paths then those applications would blow up. [0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maximum-path-length-limitation https://docs.microsoft.com/en-us/windows/win32/fileio/naming... [1] https://github.com/UweKeim/ZetaLongPaths https://github.com/UweKeim/ZetaLongPaths