>>A while back I was doing some work with the Robocopy utility. It supports long fully-qualified file names, apparently up to 32K. ISTR reading some article at the time, that commented that it does this by using APIs that are present and available for NTFS volumes but not commonly used by most file-handling utilities.
>>
>>I can't remember what those APIs are, but if you're working from .Net there seem to be some results if you Google [.net long file name support].
>>
>>If that doesn't work you might be able to use Robocopy itself in a kludgy workaround. Suppose you know the file name you're looking for (could be long), and the folder it's supposed to be in (could be long too). What you could do is:
>>
>>- Create a temp folder somewhere
>>- Use Robocopy to copy the source folder to the temp folder, limiting the file list to just the file name you want (Robocopy is folder-oriented, not file-oriented)
>>- If the file appears in the temp folder, it was present in the source
>>
>>It seems there is even a /L (list) switch for Robocopy, that just lists files that would be copied, without actually doing anything. That might be very useful for your needs. http://ss64.com/nt/robocopy.html
>
>Yes, this would do for identifying the presence of a file. However, as mentioned in this thread, as none of the .NET classes support such, it is pratically impossible to work with such a file as every manipulation I would do with the file, such as zipping, unzipping, renaming, moving, deleting, file directory list, filtering, copying, executing, etc., which requires several of .NET classes, would not work.

In that case, the 3 blog entries at http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx are probably worth a look.