Я столкнулся с библиотекой c для открытия файлов с учетом имени файла Unicode. Прежде чем открыть файл, он сначала преобразует имя файла в путь, добавив "\\? \". Есть ли причина делать это иначе, чем увеличить максимальное количество символов, допустимых в пути, за эту статью msdn?
Похоже, что эти "\\? \" пути требуют Unicode-версий Windows API и стандартной библиотеки.
Да, это только для этой цели. Однако вы, скорее всего, столкнетесь с проблемами совместимости, если решите создать пути по длине MAX_PATH. Например, оболочка проводника и командная строка (по крайней мере, на XP, я не знаю о Vista) не могут обрабатывать пути по этой длине и возвращать ошибки.
Лучше всего использовать этот метод, вероятно, не для создания новых файлов, а для управления существующими файлами, которые кто-то еще мог создать.
Мне удалось создать файловый сервер, который обычно получал бы файлы с 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. И снова префикс позволяет вам и вашим скриптам обрабатывать эти файлы.
Я думаю, первое, что нужно отметить, это то, что "\\? \" не делает путь UNC-путём. Вы были более точны во второй раз, когда вы назвали его UNC-образным путем. Но даже тогда сходство возникает только при наличии двух обратных косых черт с самого начала. Это действительно не имеет никакого отношения к UNC. Это подкреплено тем фактом, что вам нужно использовать еще больше символов, чтобы получить UNC-путь с префиксом "\\? \".
Я думаю, у вас есть все основания использовать этот префикс. Он снимает ограничение максимальной длины, как описано в цитируемой статье. И это применимо только к дорожкам Unicode; не-Unicode-пути не позволяют избежать ограничения с помощью этого префикса.
Следует отметить, что префикс не допускается для относительных путей, только для абсолютных. Возможно, вы захотите дважды проверить, что ваша библиотека C соблюдает это ограничение.
Помимо более длинных путей, префикс "\\? \" также позволяет использовать имена файлов и каталогов, такие как "con" и "aux". Обычно Windows интерпретирует их как старомодные DOS-устройства.
Я писал код Windows с 1995 года, и хотя я знаю этот префикс, у меня никогда не было причин использовать его. Насколько мне известно, увеличение длины пути за пределами MAX_PATH является для него единственной причиной, и ни я, ни кто-либо из моих клиентов программ никогда не делали этого, насколько мне известно.