C# How can I solve limitations when using DirectoryInfo?
Asked Answered
L

5

10

When I recursive through some folders and files, I encounter this error:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directoryname must be less than 248 characters.

Here's my function

private void ProcessDirectory(DirectoryInfo di)
{
    try
    {
        DirectoryInfo[] diArr = di.GetDirectories();

        foreach (DirectoryInfo directoryInfo in diArr)
        {
            if (StopCheck)
                    return;
            ProcessDirectory(directoryInfo);
        }
        ProcessFile(di);
    }
    catch (Exception e)
    {
        listBoxError.Items.Add(e.Message);
    }

    TextBoxCurrentFolder.Text = di.ToString();
}

I cannot make the directory names shorter, because I'm not allowed too so... How can I solve this problem?

Added: Here's the other function:

private void ProcessFile(DirectoryInfo di)
{
    try
    {
        FileInfo[] fileInfo = di.GetFiles();

        if (fileInfo.LongLength != 0)
        {
            foreach (FileInfo info in fileInfo)
            {
                Size += info.Length;
                CountFile++;
            }
        }
    }
    catch (Exception e)
    {
        listBoxError.Items.Add(e.Message);
    }
}

EDIT Found this where he used Zeta Long Paths: How can I use FileInfo class, avoiding PathTooLongException?

Have implemented it and now i'm going to let the program run over the night to see if it works.

EDIT Used the ZetaLongPath yesterday and it worked great! It even went through folders that needed permission access.

EDIT Instead of zetalongPath, I've used Delimon.Win32.IO.dll which i think is much better. It has the same interfaces as Win32.

Lease answered 6/3, 2012 at 12:52 Comment(8)
I guess you have to go back to plain Windows API (FindFirst*/FindNext*)Kendricks
So does the error occur from within ProcessFile(), maybe that code can be changed if we can see it?Brand
You know that you are first to the deepest subfolder before you begin to process the files?! If you want to start with the rootfolder you should move ProcessFile(di); to the start of the method.Wherever
Musefan: No the problem doesn't occur there. Of course :) added the functionLease
Tim: Yeah I know, got told that I should start from the deepest first.Lease
+AirTrickz You should accept the answer of TripleAntigen.Encage
As @TripleAntigen suggested in a comment bellow, AlphaFS github.com/alphaleonis/AlphaFS may have bugs but works fine for me to use Directory.GetFiles(,,SearchOption.AllDirectories) . Download and built in VS2017 which produce dlls for NetFx45/46/47/20, used in VS2019, nice.Frayne
Does this answer your question? Best way to resolve file path too long exceptionCulture
S
8

Here's more info about the Delimon library referred to earlier. Its a .NET Framework 4 based library on Microsoft TechNet for overcoming the long filenames problem:

Delimon.Win32.I​O Library (V4.0).

It has its own versions of key methods from System.IO. For example, you would replace:

System.IO.Directory.GetFiles 

with

Delimon.Win32.IO.Directory.GetFiles

which will let you handle long files and folders.

From the website:

Delimon.Win32.IO replaces basic file functions of System.IO and supports File & Folder names up to up to 32,767 Characters.

This Library is written on .NET Framework 4.0 and can be used either on x86 & x64 systems. The File & Folder limitations of the standard System.IO namespace can work with files that have 260 characters in a filename and 240 characters in a folder name (MAX_PATH is usually configured as 260 characters). Typically you run into the System.IO.PathTooLongException Error with the Standard .NET Library.

Sinus answered 16/2, 2013 at 5:41 Comment(2)
Heres another possible alternative called AlphaFS: github.com/alphaleonis/AlphaFSSinus
@ TripleAntigen great staff, open source. Delimon.Win32.IO seems to be close sourced from a company. AlphaFS may have bugs but works fine for me to use Directory.GetFiles(,,SearchOption.AllDirectories). Download and built in VS2017 which produce dlls for NetFx45/46/47/20, used in VS2019Frayne
U
2

This is a known limitation in Windows: http://msdn.microsoft.com/en-us/library/aa365247.aspx

I don't believe you'll be able to get around it, so whoever is telling you that you aren't allowed to make them shorter, you'll have a pretty solid argument as to why you have to.

The only real alternative is to move the deep folder somewhere else, maybe right at the root of your drive.

EDIT: Actually there may be a workaround: http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html

Unalterable answered 6/3, 2012 at 12:57 Comment(0)
O
1

You'll have to use P/Invoke and the Unicode version of the Win32 API functions. You'll need FindFirstFile, FindNextFile and FindClose functions.

Also see:

Olvera answered 6/3, 2012 at 13:0 Comment(0)
L
0

You can use the subst command. It creates a virtual drive starting at whatever folder you pass as parameter.

For example, you can turn the path c:\aaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaa into the drive R: and continue exploring the subfolders of c:\aaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaa thru R:...

Do you know what I mean?

Lur answered 6/3, 2012 at 12:58 Comment(0)
D
-1

I also recommend reading this three-part blog post from the BCL Team, published in 2007, but relating specifically to the limitations of DirectoryInfo when it comes to deeply nested folders. It covers the history of the MAX_PATH limitation, the newer \?\ path format, and various .NET-based solutions and workarounds.

Comprehensive, though perhaps a bit dated.

Dutiable answered 6/3, 2012 at 13:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.