3 ms·

">MAX_PATH paths" How does this happen?

• xenadu02 12y ago
  Technical debt that keeps on giving. Today there are N applications. "We can't increase MAX_PATH because it will break existing applications!" Tomorrow there are N+M applications. "We can't increase MAX_PATH because it will break existing applications!" Repeat forever. Any time you are faced with a hard technical decision like this, the pain will always be least if you make the change either: 1. During another transition (e.g. 16-bit to 32-bit, or 32-bit to 64-bit). Microsoft could have required all 64-bit Windows apps to adopt a larger MAX_PATH, among other things. 2. Right NOW, because there will never be an easier time to make the change. The overall pain to all parties will only increase over time.
• drv 12y ago
  This article has a pretty nice overview: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... The MAX_PATH limitation can be avoided by using the \\?\ prefix (which also disables some kinds of path normalization, like converting / to \) or by using paths relative to the current directory. Unfortunately, most tools (including Windows Explorer and other Microsoft software) still don't work with paths longer than MAX_PATH.
• noinsight 12y ago
  It happens on pretty much every network share, especially when you address it with an UNC path ("\\server\share\...") instead of mapping it as a drive. If you have non-Windows users using the share it's pretty much guaranteed, since they don't have a problem with it - only Windows chokes on this. Even Windows users manage to somehow create such paths (files) occasionally. Then you need to break out cmd.exe or somesuch because Explorer can't touch them.