Есть ли способ обойти исключение PathTooLongException, которое иногда выдает FileSystemInfo.Fullname? - PullRequest
9 голосов
/ 23 августа 2011

У меня на жестком диске есть файлы, которые выдают PathTooLongException, когда я получаю доступ к свойству Fullname объекта FileSystemInfo. Есть ли способ обойти это (кроме переименования файлов, что не вариант)?

http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#maxpath, упомянутый в других ответах, предлагает добавить префикс "\? \" К имени файла, но в этом случае DirectoryInfo.GetFileSystemInfos() отвечает за создание FileSystemInfo объектов, а DirectoryInfo - нет. принять этот префикс, чтобы его нельзя было использовать.

Ответ « PathTooLongException в коде C # » не помогает, потому что это многопоточное приложение, и я не могу продолжать изменять текущий путь приложения.

Действительно ли мне нужно все делать с PInvoke, чтобы можно было прочитать каждый файл на жестком диске?

Ответы [ 5 ]

3 голосов
/ 23 августа 2011

Это выглядит интересно ... Codeplex Long Path Wrapper

Оболочка для длинных путей обеспечивает функциональность, облегчающую работу с путями, длина которых превышает текущий предел в 259 символов в пространстве имен System.IO. Используя классы длинных путей, проекты теперь могут использовать пути длиной до 32 000 символов.

Я попробую, хотя сразу отмечу, что он не предоставляет эквивалентного метода для DirectoryInfo.GetFileSystemInfos(), поэтому потребуется некоторая модификация.

2 голосов
/ 27 мая 2017

Начиная с Windows 10 (или Windows Server 2016) и .Net 4.6.2, длинные пути могут поддерживаться напрямую, если параметр реестра включен, а ваше приложение помечено как «поддерживающее длинные пути».

Доступ к настройке можно получить через редактор локальной групповой политики (gpedit.msc), в разделе Конфигурация компьютера > Административные шаблоны > Все настройки > Включить длинные пути Win32

Чтобы пометить ваше приложение как «поддерживающее длинный путь», добавьте этот раздел в файл манифеста:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
  <windowsSettings>
    <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
  </windowsSettings>
</application>

Кроме того, если ваше приложение предназначено для версии .Net framework ранее, чем 4.6.2 , вам необходимо добавить раздел в файл App.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" />
  </runtime>
</configuration>

Для получения дополнительной информации см .:
https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/ https://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx

(Насколько мне известно, это влияет только на базовые API-интерфейсы файловой системы Windows. Не-файловые API-интерфейсы могут по-прежнему ограничиваться 260 символами)

2 голосов
/ 23 августа 2011

Корректная работа с длинными путями не так уж и сложна - например, SetACL делает это. Но:

  • .NET Framework классы не поддерживают длинные пути, поэтому вы не можете их использовать
  • вам нужно написать оболочку для каждой функции API файловой системы, чтобы она использовала правильный длинный путь как для локальных, так и для UNC-путей

Вот документация по MSDN о длинных путях: http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx

2 голосов
/ 23 августа 2011

Существует не так много программ, способных выдержать путь длиной более 259 символов.Довольно жесткий предел для слоя winapi, MAX_PATH везде.Это было рассмотрено для .NET, но без конкретных результатов.Пост серии блогов заканчивается здесь ссылками на предыдущие записи внизу.

0 голосов
/ 09 декабря 2015

Для .net 4.0 Delimon.Win32.I O Библиотека (V4.0) . Он обещает очень длинные пути без изменений кода. Но, похоже, есть некоторые проблемы.

...