C ++ WinAPI: обработка длинных путей / имен файлов

Question

Я смотрю на обработку более длинных путей к файлам в моем приложении Windows.

В настоящее время у меня есть текстовое поле (поле редактирования), в котором пользователь может ввести абсолютный путь к файлу. Затем я прочитал этот типизированный путь к файлу, используя GetWindowText, в строку, объявленную так: TCHAR FilePath[MAX_PATH];

Очевидно, здесь я полагаюсь на константу MAX_PATH, которая ограничивает меня 260 символами. Поэтому для обработки более длинных имен файлов / путей я мог бы просто расширить свой массив TCHAR следующим образом: TCHAR FilePath[32767];.

Или есть лучший способ? Могу ли я использовать массив переменной длины? (TCHAR FilePath[]; это вообще возможно в C ++? - извините, я довольно новичок в этом).

Спасибо заранее!

---

Вот весь фрагмент кода, о котором я упоминал выше:

TCHAR FilePath[MAX_PATH];
ZeroMemory(&FilePath, sizeof(FilePath));
GetWindowText(hWndFilePath, FilePath, MAX_PATH);

Answer 1

Существует ряд ограничений в отношении путей к файлам в Windows. По умолчанию длина пути не может превышать 260 символов, для чего и используется константа MAX_PATH.

Однако вы можете получать доступ к более длинным путям - с определенными ограничениями - путем добавления префикса пути к «\\? \». Однако ограничения на использование префикса «\\? \» Обычно перевешивают преимущество:

1. Существует ряд API-интерфейсов Win32, которые не поддерживают пути с этим префиксом (например, LoadLibrary всегда будет давать сбой на пути, длина которого превышает 260 символов)
2. Правила канонизации Win32 не вступают в силу при использовании префикса "\\? \". Например, по умолчанию "/" в путях преобразуется в "\", "." и ".." преобразуются в ссылки на текущий и родительский каталоги соответственно и т. д., при использовании префикса "\\? \" ничего этого не происходит.
3. Если вы можете изменить вашу программу для поддержки более длинных путей, другие программы могут не открыть файлы, которые вы создали. Это будет иметь место, если эти другие программы не также используют префикс "\\? \".

Если честно, пункт № 2 является настоящим убийцей: вы открываете себя для всех видов неприятностей при использовании префикса "\\? \", И вам, по сути, нужно заново реализовать правила канонизации Win32, если вы идете этот маршрут.

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

Answer 2

Это зависит от того, какую программу вы пишете.Моя собственная стратегия обычно заключалась в том, чтобы ограничить путь создание до MAX_PATH длиной, но иметь возможность читать существующие данные из более длинных путей (используя префикс "\\? \", Который упоминает Дин вего ответ).Хотя есть исключения из этого - просто, например, программа резервного копирования должна принимать длинные пути и должна точно воспроизводить то, что было указано в качестве ввода.

Хотя Дин, безусловно, прав, Windows не канонизирует длинные пути дляВы, я не нашел, что это, как правило, вызывает большую озабоченность.Как правило, это не означает написание собственного кода для канонизации пути - обычно это означает, что пользователь должен вводить пути таким образом, который просто не генерирует такие вещи.

Answer 3

Нет, потому что, если вы получите более длинный путь, Windows не сможет его принять. Таким образом, хотя технически вы можете хранить больше символов, чем в своем буфере, вы никогда не сможете использовать результат filepath.