В Windows, когда вы должны использовать префикс имени файла \\\\? \\?

Question

Я наткнулся на библиотеку c для открытия файлов по имени файла Unicode. Перед тем, как открыть файл, он сначала преобразует имя файла в путь, добавив "\\? \". Есть ли какая-либо причина сделать это, кроме как увеличить максимальное количество символов, разрешенных в пути, для этой статьи MSDN ?

Похоже, что эти пути \\? \ "Требуют Unicode-версий Windows API и стандартной библиотеки.

Answer 1

Да, это только для этой цели. Однако вы, скорее всего, столкнетесь с проблемами совместимости, если решите создать пути длиной MAX_PATH. Например, оболочка проводника и командная строка (по крайней мере, в XP, я не знаю о Vista) не могут обрабатывать пути по этой длине и возвращают ошибки.

Answer 2

Лучше всего использовать этот метод, вероятно, не для создания новых файлов, а для управления существующими файлами, которые, возможно, создал кто-то другой.

Я управлял файловым сервером, который обычно получал файлы с path_length > MAX_PATH. Видите ли, пользователи видели файлы как H:\myfile.txt, но на сервере это было на самом деле H:\users\username\myfile.txt. Таким образом, если пользователь создал файл с точно MAX_PATH символами, на сервере это было MAX_PATH+len("users\username").

(Создание файла с символами MAX_PATH не так уж редко, поскольку при сохранении веб-страницы в Internet Explorer в качестве имени файла используется заголовок страницы, который может быть довольно длинным для некоторых страниц).

Кроме того, разделяя диск (по сети или через USB) с компьютером Mac или Linux, вы можете найти файлы с именами, такими как con, prn или lpt1. И снова префикс позволяет вам и вашим сценариям обрабатывать эти файлы.

Answer 3

Помимо использования более длинных путей, префикс "\\? \" Также позволяет вам использовать файлы и имена каталогов, такие как "con" и "aux". Обычно Windows интерпретирует их как устаревшие устройства DOS.

Answer 4

Я думаю, что первое, что нужно отметить, это то, что \\? \ Не делает путь UNC-путем. Вы были более точны во второй раз, когда назвали его UNC- style path. Но даже тогда, сходство только из-за наличия двух обратных косых черт в начале. Это действительно не имеет ничего общего с UNC. Это подтверждается тем фактом, что вам нужно использовать еще больше символов, чтобы получить UNC-путь с префиксом \\? \.

Я думаю, у вас есть все основания для использования этого префикса. Он снимает ограничение максимальной длины, как описано в статье, которую вы цитировали. И это относится только к путям Unicode; пути не в Юникоде не позволяют избежать ограничения при использовании этого префикса.

Следует отметить, что префикс не разрешен для относительных путей, только для абсолютных. Возможно, вы захотите перепроверить, что ваша библиотека C соблюдает это ограничение.

Answer 5

Я пишу код Windows с 1995 года, и хотя я знаю об этом префиксе, у меня никогда не было причин использовать его. Увеличение длины пути до MAX_PATH, кажется, единственная причина этого, и, насколько мне известно, ни я, ни клиенты моих программ никогда не делали этого.