Должен ли я обрабатывать файлы дольше MAX_PATH?

Просто был интересный случай.

В моем программном обеспечении сообщалось о сбое, вызванном длительностью пути, превышающей MAX_PATH.

Путь был просто обычным старым документом в "Мои документы", например:

C:\Documents and Settings\Bill\Some Stupid FOlder Name\A really ridiculously long file thats really very very very..........very long.pdf

Общая длина 269 символов (MAX_PATH == 260).

Пользователь не использовал внешний жесткий диск или что-то в этом роде. Это был файл на управляемом Windows диске.

Итак, мой вопрос в этом. Мне все равно?

Я не говорю, могу ли я иметь дело с длинными путями, я спрашиваю, должен ли я. Да, я знаю об Unicode-хакете на некоторых API-интерфейсах Win32, но кажется, что этот хак не без риск (поскольку он изменяет поведение пути анализа API-интерфейсов), а также не поддерживается всеми API-интерфейсами.

Так или иначе, позвольте мне просто указать свою позицию/утверждения:

Сначала, предположительно, единственный способ, которым пользователь смог нарушить это ограничение, - это приложение, которое она использует, использует специальный Unicode-хак. Это файл PDF, поэтому, возможно, инструмент PDF, который она использовал, использует этот хак.
Я попытался воспроизвести это (используя юникод-хак) и поэкспериментировал. Я обнаружил, что, хотя файл появляется в Проводнике, я ничего не могу с этим поделать. Я не могу открыть его, я не могу выбрать "Свойства" (Windows 7). Другие распространенные приложения не могут открыть файл (например, IE, Firefox, Notepad). Explorer также не позволит мне создавать файлы /dirs, которые слишком длинны - он просто отказывается. То же для инструмента командной строки cmd.exe.

Таким образом, в принципе, можно было бы взглянуть на это так: инструмент румян позволил пользователю создать файл, который недоступен для большого количества Windows (например, Explorer). Я мог бы подумать, что мне не придется иметь дело с этим.

(В стороне, это не голосование одобрения для короткой максимальной длины пути: я думаю, что 260 символов - это шутка, я просто говорю, что если оболочка Windows и некоторые API не могут обрабатывать > 260, тогда почему я должен?).

Итак, это справедливое мнение? Должен ли я сказать "Не моя проблема"?

UPDATE: У меня был другой пользователь с той же проблемой. На этот раз mp3 файл. Я что-то упускаю? Как эти пользователи могут создавать файлы, нарушающие правило MAX_PATH?

Ответ 1

Это не настоящая проблема. NTFS поддерживает имена файлов до 32K (32,767 широких символов). Вам нужен только правильный API и правильный синтаксис имен файлов. Базовое правило: имя файла должно начинаться с '\\?\' (см. http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx), например \\?\C:\Temp. Тот же синтаксис, который вы можете использовать с UNC: \\?\UNC\Server\share\Path. Важно понимать, что вы можете использовать только небольшое подмножество функции API. Например, посмотрите описание функций MSDN

CreateFile
CreateDirectory 
MoveFile

и т.д.

вы найдете текст вроде:

В версии ANSI этой функции, имя ограничено MAX_PATH персонажи. Чтобы распространить этот предел на 32 767 символов, вызовите Unicode-версия функции и добавьте "\? \" к пути. Для большего информацию см. в разделе Именование файла.

Эти функции можно безопасно использовать. Если у вас есть дескриптор файла из CreateFile, вы можете использовать все другие функции, используемые hFile (ReadFile, WriteFile и т.д.) Без каких-либо ограничений.

Если вы пишете такую программу, как сканер вирусов или программное обеспечение для резервного копирования или какое-то хорошее программное обеспечение, работающее на сервере, вы должны написать свою программу, чтобы все файловые операции поддерживали имена файлов до 32K, а не MAX_PATH.

Ответ 2

Это ограничение испечено во множество программ, написанных на C или С++. В том числе код MSFT, хотя они были отрываются от него. Это лишь частично ограничение Win32, оно по-прежнему имеет жесткий верхний предел длины имени файла (не путь) через WIN32_FIND_DATA, например. Одна из причин того, что .NET имеет ограничения длины. Это не исчезнет в ближайшее время, Win32 по-прежнему будет сильным, и строка C камня камня не исчезнет.

У вашего клиента будет мало симпатии к нему, без сомнения, вероятно, пока вы не сможете показать им другую программу, которая не срабатывает одинаково. Однако удостоверьтесь, что ваш код надежно может обнаружить переполнение буфера строки, за которым следует разумная диагностика. Никакой симпатии к программам бомбардировки на куче коррупции.

Ответ 3

Как вы упомянули, многие из функций Windows Shell работают только с путями до MAX_PATH. Windows XP, и я считаю, что Vista имеет проблемы в проводнике при вложенности каталогов с длинными именами файлов. Я не проверял Windows 7 - возможно, они исправили это. Это, к сожалению, означает, что пользователям трудно просматривать этот файл.

Если вы действительно хотите поддерживать длинные пути, вам нужно будет проверить все функции, которые вы используете в Shell32.dll, которые принимают пути, чтобы гарантировать, что они поддерживают длинные пути. Для тех, кто этого не делает, вам придется использовать их самостоятельно, используя функции Kernel32.

Если вы решите использовать Shell32 и ограничены MAX_PATH, рекомендуется написать код для поддержки длинных путей к файлам. Если Microsoft позже изменит Shell32 (или создаст альтернативу), вы сможете лучше разместить поддержку для них.

Чтобы добавить еще одну пару аспектов в проблему, помните, что имена файлов - UTF-16, и вы можете столкнуться с файловыми системами NTFS или FAT, которые могут быть чувствительны к регистру!

Ответ 4

Ваши собственные API не должны жестко кодировать фиксированный предел длины пути (или любых других жестких ограничений); однако вы не должны нарушать предварительные условия системных API-интерфейсов для выполнения какой-либо задачи. IMHO, тот факт, что Windows ограничивает длину имен путей, является абсурдным и должен считаться ошибкой. Тем не менее, я бы не предложил, чтобы вы не пытались использовать различные системные API, отличные от документированных, даже если это приводит к определенному нежелательному поведению, такому как ограничения максимальной длины пути. Итак, короче, ваше мнение совершенно справедливо; если ОС не поддерживает его, то ОС не поддерживает его. Тем не менее, вы можете дать понять пользователям, что это ограничение Windows, а не вашего собственного кода.

Ответ 5

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

Пример:

"C:\My veeeeeeeeeeeeeeeeeeeeery папка looooooooooooooooooong" может использоваться как "данные". Затем пользователи могут получить доступ к этой папке через UNC-путь\\компьютер\данные или (еще короче) через букву диска (M: \), предполагая, что M: отображается на\\компьютер\данные.

Это часто происходит на файловых серверах.

Ответ 6

Контуры часто могут быть больше 260, например, когда символические ссылки вставляются и повторяются снова и снова иногда даже специально. Я думаю, программисты должны подумать, хотят ли они, чтобы их программа обрабатывала эти безумно большие пути или нет. ИМО, 260 - это ПЛОТНОСТЬ пространства, но это только я. Мой ответ на это:

, если вам нужно так глубоко спросить себя о том, чтобы нарушить предел 260 char, то это, вероятно, то, что вы должны делать. Мы часто ищем подтверждение, когда мы собираемся сделать что-то, о чем мы не уверены...

Я думаю, что максимальный путь в API-интерфейсе составляет около 32 тыс., но это зависит от вас. Назад в тот день, когда был довольно большой кусок изменений (половина всего сегмента памяти!! sheesh!), Но теперь, в прозрачной среде с сегментацией, в которой мы живем, где все память накладывается вместе на квартиру, 32k is nothin '... Пути AFAIK не должны быть такими длинными, если вы не используете какой-то причудливый язык юникода, который требует много других символов и т.д. и т.д., мы могли бы проболтать об этом весь день, но вы получите эту идею. Надеюсь, это поможет..... или болит?

Ответ 7

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

Итак, я понимаю, что NTFS поддерживает имена файлов длиной до 32.767 символов, однако, согласно знаниям, FAT16 поддерживает только 11 имен символов символов, 8 + 3, поэтому в операционных системах reallity должна быть функция, которую наша программа может вызвать для dertemine максимальный размер имени файла, просто потому, что все файловые системы имеют разные ограничения, включая длину имени файла.

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

Ответ 8

Не точно ответ на ваш конкретный вопрос, но он может помочь тем, кому нужно обрабатывать длинные имена файлов.

Библиотека Delimon представляет собой основанную на .NET Framework 4 библиотеку в Microsoft TechNet для преодоления проблемы с длинными именами файлов:

Библиотека Delimon.Win32.I O (V4.0).

Он имеет собственные версии ключевых методов из System.IO. Например, вы бы заменили:

System.IO.Directory.GetFiles

Delimon.Win32.IO.Directory.GetFiles

который позволит вам обрабатывать длинные файлы и папки.

С веб-сайта:

Delimon.Win32.IO заменяет основные файловые функции System.IO и поддерживает имена файлов и папок до 32 767 символов.

Эта библиотека написана на платформе .NET Framework 4.0 и может использоваться либо на системах x86 и x64. Ограничения по файлу и папке стандарта Пространство имен System.IO может работать с файлами с 260 символами в имя файла и 240 символов в имени папки (MAX_PATH обычно настроено на 260 символов). Обычно вы сталкиваетесь с Ошибка System.IO.PathTooLongException в стандартной библиотеке .NET.