How can I use FileInfo class, avoiding PathTooLongException?
Asked Answered
J

4

15

How can I use (to avoid PathTooLongException):

System.IO.FileInfo

with paths bigger than 260 chars?

Are there similar classes/methods that return the same result of FileInfo class?

Jestinejesting answered 31/8, 2009 at 13:1 Comment(0)
G
11

From what I know it is not easily possible. While it is possible to use workaround for streams as phoenix mentioned, it is not possible for file names handling. Internally every class that works with file names perform checks for long file names.

You can instantiate FileInfo and fill private memebers using reflection (however this is not recommended) and get FileInfo pointing to file with long path. But when you try to use this object you will still receive PathTooLongException exceptions, because for example, Path class (used heavily by FileInfo) checks for long path on every method call.

So, there is only one right way to get problem free long path support - implement your own set of classes that will mimic FileInfo behavior. It is not very complex (only security maybe), but time-consuming.

Update: Here even two ready solutions for this problem: AlpfaFS and Zeta Long Paths

Giovannigip answered 31/8, 2009 at 13:18 Comment(1)
+1; the Zeta Long Paths link gave me exactly what I needed. The FindFirstFile API call is the key element to replicate FileInfo.Semivitreous
M
7

Here at work we deal with long paths quite frequently, and we therefore had to basically roll our own System.IO to do it. Well not really, but we rewrote File, Directory, FileInfo, DirectoryInfo and Path just to name a few. The basic premise is that it's all possible from a Win32 API perspective, so all you really need to do at the end of the day is invoke the Unicode versions of the Win32 API functions, and then you're good. It's alot of work, and can be a pain in the ass at times, but there's really no better way to do it.

Modica answered 31/8, 2009 at 13:25 Comment(5)
how do your new classes look, are they 100% hand written or do you subclass the built in File class within your File class?Counterpane
Well, File is actually a static class so you can't inherit from it, but most of the classes you'd think of subclassing (FileInfo, DirectoryInfo) are sealed, so you can't subclass them. We wrote them all from scratch. I won't lie, we did use Reflector ALOT :)Modica
@Modica interesting. Is there any possibility to open-source this work? Could save dozens of hours of multiple developers around the globe, methinks.Ingles
@Ingles This answer is six years old, and I'm far removed from that job at this point :-( So, no I do not have access to this code anymore. You're making me thing though that this would be an interesting side project to start up.... Now I just need to find time :-)Modica
@Modica no worries :-) I'm testing ZetaLongPaths and it seems to suit the majority of my needs. Sometimes I needed to use the Win API directly - not beautiful, but I'm okay with it. But it's indeed a good side project!Ingles
P
1

There's a great library on Microsoft TechNet for overcoming the long filenames problem, it's called Delimon.Win32.I​O Library (V4.0) and 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.

Polycotyledon answered 16/2, 2013 at 5:46 Comment(0)
K
1

I only needed to use the FullName property but was also receiving the PathTooLongException.

Using reflection to extract the FullPath value was enough to solve my problem:

private static string GetFullPath(FileInfo src)
{
    return (string)src.GetType()
        .GetField("FullPath", BindingFlags.Instance|BindingFlags.NonPublic)
        .GetValue(src);
}
Kirkcudbright answered 27/8, 2014 at 12:10 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.