Maximum for MaxPath in CLR is 260 characters
The maximum amount of characters is defined by MAX_PATH in the Win32 API library. This setting is 260 and that same setting is used, hard-coded, inside the CLR BCL. A path reaching that amount of characters is likely to cause trouble (see aside below). This maximum is the maximum for the good old FAT and FAT32.
Conversely, the NTFS filesystem, used on the majority of Windows installations by default, has a maximum of 32767 characters and supports unicode (in an implementation where each character can take up 2 bytes, i.e., UCS-2, not UTF-32). But even in NTFS, a single path segment must not exceed 255 characters. While NTFS supports very long filenames, most applications, including any .NET application relying on System.IO, will not be able to see these filenames.
Why 260 and not 256? Because the drive specifier, the first backslash and the trailing null-terminating character are not part of the length-limitations. You can get this information for Windows using GetVolumeInformation, which you should query for each volume individually (each volume can have a different max size).
I assumed Windows. Linux and other OS's may and will be different. Since Windows 10, build 1607, this limit has been removed, see below for details.
As a general advice, you should not rely on any of these numbers. Instead, catch the PathTooLongException if you want to inform users that the path is too long:
try
{
SetCurrentDirectory(longPath);
}
catch(PathTooLongException exc)
{
Console.WriteLine("The pathname was too long");
}
Note: the code above will throw when you exceed 260 characters, which is the limit that the CLR is imposing on you. This is not the real limit (see first paragraph).
As an aside on .NET
Microsoft has confirmed that it is a problem with the current implementation(s) of .NET that you cannot reliably find out what the maximum path size is as supported by the CLR. If you want to get this information programmatically, use the Path.MaxPath property. However, the property is internal which means you can only access it through reflection and that you cannot guarantee it will work across versions, or on other BCL implementations (Mono):
// reflection
FieldInfo maxPathField = typeof(Path).GetField("MaxPath",
BindingFlags.Static |
BindingFlags.GetField |
BindingFlags.NonPublic );
// invoke the field gettor, which returns 260
int MaxPathLength = (int) maxPathField.GetValue(null);
Note: this gives you the maximum path as it is used by Microsoft's .NET implementation. There's a different value in the BCL for the maximum directory size, Path.MAX_DIRECTORY_PATH, but even inside the BCL this is never used. If you ever create a directory equal to this size, you will not be able to place any files inside that directory. Worse, just opening it will raise an error (because of the mandatory semi-directory aliases . and .., which causes many API's to crash).
UPDATE: as of Windows 10 Build 1607 you can remove the limit via OptIn in the Registry:
Starting in Windows 10, version 1607, MAX_PATH limitations have
been removed from common Win32 file and directory functions. However,
you must opt-in to the new behavior.
A registry key allows you to
enable or disable the new long path behavior. To enable long path
behavior set the registry key at
HKLMSYSTEMCurrentControlSetControlFileSystem LongPathsEnabled
(Type: REG_DWORD).
More info is in the updated entry on MSDN, section titled 'Maximum Path Length Limitation'.
