Доступ к файлам с недопустимыми именами в Windows

Я запускаю Windows 7 в VirtualBox на хосте OS X 10.8. На хосте есть общая папка с файлом с именем >>>FILE<<< внутри. Судя по всему, у самой OS X нет проблем с такими именами файлов. К сожалению, я не могу открыть эти файлы в Windows 7 из-за <s и >s в имени. В C этот вызов не работает:

CreateFileW(
    L"\\\\VBOXSVR\\ft1\\>>>FILE<<<",
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL,
    NULL
    );

GetLastError возвращает ERROR_INVALID_NAME (123). Если я изменю имя файла на FILE, я получу действительный дескриптор, и все будет в порядке.

Есть ли в Windows известный способ доступа к этим файлам с недопустимыми символами в именах? Предположим, продуктивная среда без прямого доступа для записи к файловой системе хоста.


macos filenames winapi shared-directory createfile
person GOTO 0    schedule 07.01.2013    source источник
comment
Обеспечивает ли удаленная файловая система короткие имена файлов? Если это так, вы можете получить доступ к файлу, используя его короткое имя.   -  person Jonathan Potter    schedule 08.01.2013
comment
@JonathanPotter, ваша идея хороша, но нет, файловая система не поддерживает короткие имена файлов, и VirtualBox не использует их совместно. Это может работать с папкой тома NTFS, совместно используемой в реальной сети с соответствующим драйвером. Краткое имя файла будет выглядеть как ___FIL~1.   -  person GOTO 0    schedule 09.01.2013

Ответы (2)


arrow_upward
2
arrow_downward

Ответ @jcophenha был на правильном пути. Однако, если вы прочитаете на странице, на которую ссылается @jcopenha, указано, что префикс \\?\ предназначен только для локальных путей. Вы должны использовать префикс \\?\UNC\ вместо путей UNC, например:

L"\\\\?\\UNC\\VBOXSVR\\ft1\\>>>FILE<<<"
person Remy Lebeau    schedule 07.01.2013
comment
Извините, похоже, это тоже не работает. Это расстраивает. - person GOTO 0; 08.01.2013
comment
Если \\?\UNC\server\share не работает, то вам не повезло. Удаленный файл необходимо переименовать во что-то более кросс-платформенное (или, по крайней мере, создать символическую ссылку, которая сопоставляется с реальным файлом внутри и доступна на разных платформах). - person Remy Lebeau; 08.01.2013
comment
@Remy Проблема в том, что и <, и > являются зарезервированными символами. - person David Heffernan; 08.01.2013
comment
Если вы читали связанную статью, цель префиксов \\?\ и \\?\UNC\ — отключить синтаксический анализ, который включает игнорирование зарезервированных символов. - person Remy Lebeau; 08.01.2013

arrow_upward
1
arrow_downward

Символы < и > нельзя использовать в имени файла Windows. И поэтому этот файл не может быть открыт под Win32.

В документации по соглашениям об именах перечислены следующие зарезервированные символы. :

  • < (меньше, чем)
  • > (больше чем)
  • : (двоеточие)
  • "(двойная кавычка)
  • / (косая черта)
  • \ (обратная косая черта)
  • | (вертикальный брус или труба)
  • ? (вопросительный знак)
  • * (звездочка)

В этой области Windows существенно отличается от систем *nix. В * nix обычно нет таких принудительных ограничений ОС на символы, которые можно использовать в файле. Как однажды обнаружил мой друг, когда он попытался удалить файл с именем * и понес самые печальные последствия.

Теперь можно предположить, что эти ограничения не применяются при использовании собственного API. Вы можете попробовать открыть файл с помощью NtCreateFile. Это может просто сработать!

person David Heffernan    schedule 07.01.2013
comment
Боюсь, вы можете быть правы. NtCreateFile не помогло, я смог открыть файл только после удаления < и > из имени. Как ни странно, другие запрещенные символы, такие как вертикальная черта |, не вызывают проблем. - person GOTO 0; 08.01.2013