Evosoul04 Ответов: 2

Как заставить максимальную длину пути содержать более 260 символов


Всем привет,

У меня проблема с экономией. Мне нужно знать, какой путь длиннее 260 символов (к сожалению, они должны быть такими длинными. Это не моя идея!)

Я нашел вот это:
[^]

Я попробовал\\?\, но это не сработало.

Мой путь таков:"\\? \D:\Temp1\Data\"
В этом случае Visual Studio говорит, что существует неизвестная escape-последовательность.

Тогда я попробовал @"\\? \D:\Temp1\Data"
Visual Studio говорит, что есть знак, который не разрешен. Я думаю, что это"?"

И когда я пытаюсь сделать это без\\?\, есть исключение windows, которое говорит, что путь допускает только 260 символов.

Какую ошибку я совершил?

Надеюсь, вы сможете мне помочь.

С уважением
Ричард

Что я уже пробовал:

Эти ссылки:
https://blogs.msdn.microsoft.com/bclteam/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton/

https://msdn.microsoft.com/en-us/library/aa365247.aspx

Member 12599256

"\ \ ? "означает имя компьютера. Пример: \ \ server1\publicshare
файл примера.Удалить(@"D:\Temp1\Data\file1.txt"):

Evosoul04

В Примере MSDN говорится, что я должен использовать\\?\, когда у меня есть путь длиной более 260 символов. Или я ошибаюсь здесь? https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath

Dave Kreskowiak

Если вы пытаетесь использовать классы и методы, встроенные в систему .NET Framework.Пространство имен Io, с которым они не будут работать дольше, чем с обычными файловыми путями.

Вы должны делать то, что вы связали, и писать свои собственные методы для обработки основных файловых операций.

Не видя вашего кода, невозможно сказать вам, что вы сделали не так.

johannesnestler

Я проверил точный код из примера блога OP linked - он не работал, даже с вызовами PInvoke вместо System.IO...

Dave Kreskowiak

Я не могу проверить это прямо сейчас. У меня еще нет VS, установленного после перестройки системы, и у меня нет времени.

0x01AA

При использовании PInvoke, вы убедитесь в том, чтобы использовать Юникод ("ж") версии?

Благоговение Разработчиков:
Windows NT: вы можете использовать пути длиннее символов MAX_PATH, вызывая широкую (W) версию CreateFile и добавляя к пути"\\?\". "\ \ ? \ "Указывает функции Отключить синтаксический анализ пути. Это позволяет использовать пути длиной почти 32 000 символов Юникода. Вы должны использовать полностью квалифицированные пути с этой техникой. Это также работает с UNC-именами. "\ \ ? \ "Игнорируется как часть пути. Например, "\\?\C:\myworld\private" считается "C:\myworld\private" и "\\?\UNC-пути\tom_1\hotstuff\coolapps" рассматривается как "\\tom_1\hotstuff\coolapps".

Richard MacCutchan

Пример кода работает так, как задокументировано.

Richard Deeming

Вместо того чтобы пытаться написать код самостоятельно, почему бы не использовать предварительно построенную библиотеку, чтобы сделать эту работу за вас:
Зета Длинные Пути[^] Уве Кейма существует уже почти семь лет и, кажется, работает хорошо.

Кроме того, измените требования таким образом, чтобы вы не попробуйте разбить окна! :)

Richard MacCutchan

Смотрите мое решение ниже, ничего не сломано.

2 Ответов

Рейтинг:
12

Richard MacCutchan

Я использовал код в ссылке, которую вы предоставили, и он работал так, как ожидалось. Пожалуйста, отредактируйте свой вопрос и покажите точный код, который вы используете, чтобы мы могли увидеть, что отличается.

[редактировать]
Работает следующий код:

[DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.Bool)]
internal static extern bool DeleteFile(string lpFileName);

public static void Delete(string fileName)
{
    string formattedName = @"\\?\D:\Temp\" + fileName;
    DeleteFile(formattedName);
}

[/редактировать]


0x01AA

Кроме того, если путь больше 260 символов? Только вопрос...

Evosoul04

Спасибо, что это сработало. Но я нашел "лучшее" решение, на мой взгляд. Я использую "пакет Zeta Long Path NuGet". Он также импортирует kernel32.dll.

Richard MacCutchan

У меня нет таких длинных путей для проверки.

Рейтинг:
1

johannesnestler

Привет Evosoul04,

К сожалению, я не могу предложить никакой реальной помощи для вашей проблемы. Но, по крайней мере, я попытался следовать шагам из вашей связанной статьи в блоге. Я скопировал код в небольшой тестовый проект. Но я наблюдал такое же поведение, как и Вы - оно не сработало (система не может найти указанный путь), но я думаю, что она сделала все правильно в соответствии с: Именование файлов, путей и пространств имен (Windows)[^]
Так что, по крайней мере, вы можете сказать: у других была такая же проблема ;) - мне кажется, что мы упускаем здесь какую-то важную информацию, чтобы заставить это работать (или Microsoft изменила поведение между ними-кто знает?)

Привет из Австрии
Иоганнес


Richard MacCutchan

Смотрите мое решение ниже.