CODEWITHSUNDEEP
c#.net
Sameer
Sameer

Reputation: 3183

Why Path.GetDirectoryName function has to be dependent on 260 chars limit

public static void Main()
{
    // testing file name
    var fileName =
        "\\\\server7\\EmailAttachments\\myfolder\\abc\\2012\\1126\\e85c6b82-edc5-4ce1-9ad0-8025b92d0105-o.dom=38c55279fe168c290fb2b06a312b5d88&b=6f54a59ce903eeaff197f82937de4012.dom=38c55279fe168c290fb2b06a312b5d88&b=6f54a59ce903eeaff197f82937de4012=6f54a59ce903eeaff197f82937de4012.dom=38c55279fe168c290fb2b06a312b5d88&b=6f54a59ce903eeaff197f82937de4012";

    var directory = fileName.GetDirectory();
}

   public static string GetDirectory(this string fullyQualifiedFileName)
     {
         return Path.GetDirectoryName(fullyQualifiedFileName); // throwing exception here
     }

Getting below exception

System.IO.PathTooLongException occurred HResult=-2147024690
Message=The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. Source=mscorlib
StackTrace: at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) at System.IO.Path.GetDirectoryName(String path) at Sameer.FilePathExtension.GetDirectory(String fullyQualifiedFileName) in f:\Practice Projects\Sameer\Sameer\FilePathExtension.cs:line 137 InnerException:

I am wondering why GetDirectoryName has to be dependent on path or filename chars limit.

Upvotes: 9

Views: 3363

Answers (4)

Hakan Usakli
Hakan Usakli

Reputation: 582

There are 3 workarounds to solve the Problem with Path.GetDirectoryName as of this writing which did not exist when the original question was asked

1- For Windows 10, version 1607 and higher

To enable the built-in support for long paths in Windows 10/Windows Server 2016, use the Regedit.exe editor to set the LongPathsEnabled parameter of REG_DWORD in the registry key HKLM\SYSTEM\CurrentControlSet\ControlFileSystem with a value 1

reference https://theitbros.com/destination-path-too-long-error-when-movingcopying-a-file/

2- Change your .NET Framework Target version to 4.6.2 or higher. That version has long path support

reference https://learn.microsoft.com/en-us/dotnet/api/system.io.pathtoolongexception?redirectedfrom=MSDN&view=netframework-4.6.2

3- For .NET Apps that target Framework version 4.6.1 or older, add this to the app.config

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<startup>
<supportedRuntime version=”v4.0″ sku=”.NETFramework,Version=v4.0″/>
</startup>
<runtime>
<AppContextSwitchOverrides value=”Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false” />
</runtime>
</configuration>

This avoids to Exception for Path.GetDirectoryName that OP asks for, but you still cannot create long directories.

Reference https://theitbros.com/destination-path-too-long-error-when-movingcopying-a-file/ Solution 7

Upvotes: 1

Neel
Neel

Reputation: 11721

As documented in msdn website

"Full paths must not exceed 260 characters to maintain compatibility with Windows operating systems"

http://msdn.microsoft.com/en-us/library/system.io.pathtoolongexception(v=vs.100).aspx

and the reason behind it you can find here as documented in the below link.

Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

Another factor, which is considered more of a pain factor, is compatibility with other Windows-based applications and the Windows shell itself, which only work with paths shorter than MAX_PATH (note that the Vista shell attempts to soften this limit, briefly described below). This means that if .NET supports long paths, then we’d let you create files that you couldn’t access via Explorer or the command prompt.

That said, we realize that enforcing the 260 character limit isn’t a reasonable long-term solution. Our customers don’t run into this problem very often, but when they do, they’re extremely inconvenienced. A possible workaround is P/Invoking to the Windows APIs and using the \?\ prefix, but it would be a huge amount of code to duplicate the functionality in System.IO. So to work around the problem, customers often resort to an overhaul of directory organization, artificially shortening directory names (and updating every referencing location).

http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

Upvotes: 5

Shital Shah
Shital Shah

Reputation: 68708

It's just a validation applied to input so the output is a valid path. This is desirable in scenario where returned path would be used to make further calls to file system which is often the case. Technically you don't need to add this validation but it's a good design if it benefits your most common scenarios. In addition to this I suspect that this method uses common internal code for path parsing instead of duplicating parsing code just for this method.

Upvotes: 1

Phylogenesis
Phylogenesis

Reputation: 7880

From the MSDN documentation:

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Upvotes: 1

Related Questions