This project is read-only.

FileInfo.Length fails on a file with FullPath longer than 260 chars

Mar 31, 2011 at 8:35 PM


I tried to write a 'find duplicates' tool as an exercise and, naturally, bumped into a MAX_PATH problem with a length of the file name.

Then I found the AlphaFS, and tried it too, but found that, while it is able to return FullPath longer than 260 chars, still generates an exception when asked for a .Length on a FileInfo of a file that has .FullPath longer than 260 chars.

If I am right, the AphaFS library method Refresh() fails on a file with a long path file and records that file 'does not exist'.

Is that a bug or it is how things should be?


Mar 31, 2011 at 9:46 PM

Before you start working with long paths you should convert one through Path.GetLongPath() method.

Mar 31, 2011 at 9:50 PM

FileInfo and DirectoryInfo classes are not very efficient in enumerating file system and getting most of the file attributes. Better use Directory class and it's crawling methods for your task.


Apr 2, 2011 at 8:43 AM

thanks, now I am able to enumerate all the files on the disk, and quickly

that is, all but C:\, which itself is also a folder, and I would like to have its FileSystemEntryInfo object in the list of all files and folders on the disk

is there a way to get a FileSystemEntryInfo object of a particular single folder (including the C:\)?


Apr 2, 2011 at 4:54 PM

Glad to hear that. For this purpose use the File.GetFileSystemEntryInfo() method.

Apr 2, 2011 at 6:38 PM

excellent, thank you, it works

however, it returns a FileSystemEntryInfo of the folder *without* its .FullPath

yes, I can set the .FullPath property myself, by hand, and I do it, but that sounds a bit 'unorthogonal'

I do not have any tehnical problem with that (now, after I spotted it and found a way around it), but I thought you would like to hear that comment of mine...

thnx again :-)


Apr 2, 2011 at 7:36 PM

There were couple reasons to leave it uninitialized, and one of them to avoid double system call to get the full path of the item. Because you can use relative path, full path or full long path. And the underlying Win32 is quite non-standard and has case by case methods that just make things more over complicated. Especially when dealing with symbolic links, junctions and long paths.

Just populate it yourself now and when we'll get much better idea, we can try to re-implement this method.

Apr 2, 2011 at 11:56 PM

ok, thanks :-)

Mar 20, 2013 at 6:20 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Marked as answer by Yomodo on 1/19/2014 at 9:42 PM