4 ms·
The Windows API has a nominal 260-character pathname limit, including the leading drive letter designator (e.g., "c:\") and the trailing NULL, but the Unicode v
by xenophonf 12y ago
The Windows API has a nominal 260-character pathname limit, including the leading drive letter designator (e.g., "c:\") and the trailing NULL, but the Unicode versions of the various file system APIs have different limits, as does NTFS internally. The limit to which you're referring is actually a maximum NTFS filename (pathname component, as you said) length limit of 255 UTF-16 code points, which is also the maximum size of an HFS+ filename.
- Someone 12y agoThere are issues other than component length. HFS+ happily stores characters in paths that NTFS does not accept such as | and $ (and, I think to this day, /. Traditional Mac OS used colons as path separators. The Mac OS X Unix layer swapped colons and slashes) Also, NTFS and HFS+ use different Unicode normalization algorithms (IIRC, the Mac decomposes strings; that would make Mac paths longer in some cases) If you look closely, it is a miracle that we can have interop between different file systems at all. There is a lot of ugliness here. For example, see what Microsoft says about that 255 character limit: "The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters*)." So, before starting that copy, you really should query the target disk for its maximum pathname component length. Finding hat disk in the presence of reparse points, substituted drives, etc. may be a challenge in itself.