В какой степени Linux поддерживает имена файлов длиннее 255 байт?
Это было бы безопасностью через неизвестность. По-видимому, у клиента есть способы переопределить свой IP-адрес, и хотя теоретически вы можете обеспечить безопасность, есть много движущихся частей.
Вот сообщение на форумах OpenVPN о клиентах, переопределяющих свои IP-адреса:https://forums.openvpn.net/viewtopic.php?t=22598
Таким образом, это будет эффективно, пока кто-нибудь не догадается об этом. Однако, если кто-то подключается к сети между OpenVPN и частным сервером, у него есть доступ. Лучше всего, вероятно, заблокировать явно плохие IP-адреса, чтобы предотвратить перебор и DoS, но полагаться на сервер для аутентификации.
Если сервер ненадежен или не имеет вариантов аутентификации, вы можете использовать OpenVPN для его защиты, но я бы сделал один сервер OpenVPN на каждый частный сервер и не разрешил бы другой трафик по сети (напрямую или частная VLAN )между ними.
Ответ, как часто, "это зависит".
Рассматривая реализацию NTFS, в частности, она сообщает о максимальной длине имени файла, равной 255, дляstatvfsвызывающих абонентов, поэтому вызывающие абоненты, интерпретирующие это как ограничение в 255 -байтов, могут предварительно -избегать имен файлов, которые могут быть действительным в NTFS. Однако большинство программ не проверяют этот (или дажеNAME_MAX)заранее и полагаются на ошибки ENAMETOOLONGдля отлова ошибок. В большинстве случаев важным пределом является PATH_MAX, а не NAME_MAX; это то, что обычно используется для выделения буферов при манипулировании именами файлов (для программ, которые не выделяют буферы пути динамически, как ожидается в таких операционных системах, как Hurd , которая не имеет произвольных ограничений ).
Сама реализация NTFS проверяет длину имени файла не в байтах, а всегда как 2 -байтовых символа; имена файлов, которые не могут быть представлены в массиве из 255 2 -байтовых элементов, вызовут ошибку ENAMETOOLONG.
Обратите внимание, что NTFS обычно обрабатывается драйвером FUSE в Linux. Драйвер ядра в настоящее время поддерживает только UCS -2 символа,но драйвер FUSE поддерживает UTF -16 суррогатных пар (с соответствующим сокращением длины символов ).
Ограничение на длину имени файла действительно закодировано внутри файловой системы, т.е. ext4, изhttps://en.wikipedia.org/wiki/Ext4:
Max. filename length 255 bytes
Изhttps://en.wikipedia.org/wiki/XFS:
Max. filename length 255 bytes
Изhttps://en.wikipedia.org/wiki/Btrfs:
Max. filename length 255 ASCII characters (fewer for multibyte character encodings such as Unicode)
Изhttps://en.wikipedia.org/wiki/NTFS:
Max. filename length 255 UTF-16 code units
Обзор этих ограничений для ряда файловых систем можно найти по адресуhttps://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits. Там вы также можете увидеть, что ReiserFS имеет более высокий предел (почти 4K ), но само ядро (внутри VFS, виртуальная файловая система ядра )имеет ограничение в 255 байт.
В вашем тексте используется 160 символов UTF -16 символов, используемых в NTFS:
echo ゆく河の流れは絶えずして、しかももとの水にあらず。よどみに浮かぶうたかたは、かつ消えかつ結びて、久しくとどまりたるためしなし。世の中にある人とすみかと、またかくのごとし。たましきの都のうちに、棟を並べ、甍を争へる、高き、卑しき、人の住まひは、世々を経て尽きせぬものなれど、これをまことかと尋ぬれば、昔ありし家はまれなり。 > jp.txt
iconv -f utf-8 -t utf-16 jp.txt > jp16.txt
ls -ld jp*.txt
cat jp16.txt | hexdump -C
Это показывает 0x140 = 320 байтов (плюс 2 байта с предшествующим знаком порядка байтов (Спецификация ), если используется ). Другими словами, 160 UTF -16 символов и, следовательно, меньше 255 UTF -16 символов в NTFS, но более 255 байт.
(игнорирование символа новой строки здесь)
Итак, вот что я выяснил.
Coreutils не особенно заботятся о длине имени файла и просто работают с пользовательским вводом независимо от его длины, т.е. отсутствуют проверки.
.это работает (длина имени файла в байтах 462!):
name="和総坂裁精座回資国定裁出観産大掲記労。基利婚岡第員連聞余枚転屋内分。妹販得野取戦名力共重懲好海。要中心和権瓦教雪外間代円題気変知。貴金長情質思毎標豊装欺期権自馬。訓発宮汚祈子報議広組歴職囲世階沙飲。賞携映麻署来掲給見囲優治落取池塚賀残除捜。三売師定短部北自景訴層海全子相表。著漫寺対表前始稿殺法際込五新店広。"
cd /mnt/ntfs
touch "$name"
Даже это работает
echo 123 > "$name"
cat "$name"
123
Однако, как только вы попытаетесь скопировать указанный файл в любую из ваших классических файловых систем Linux, операция завершится ошибкой:
cp "$name" /tmp
cp: cannot stat '/tmp/和総坂裁精座回資国定裁出観産大掲記労。基利婚岡第員連聞余枚転屋内分。妹販得野取戦名力共重懲好海。要中心和権瓦教雪外間代円題気変知。貴金長情質思毎標豊装欺期権自馬。訓発宮汚祈子報議広組歴職囲世階沙飲。賞携映麻署来掲給見囲優治落取池塚賀残除捜。三売師定短部北自景訴層海全子相表。著漫寺対表前始稿殺法際込五新店広。': File name too long
. cpфактически пытался создать этот файл в /tmp, но /tmpне допускает имена файлов длиннее 255 байт.
Также мне удалось открыть этот файл в коврике для мыши (в приложении GTK ), отредактировать и сохранить его -все заработало, что означает, что ограничение в 255 байт применяется только к определенным файловым системам Linux.
Это не значит, что все будет работать. Например, мой любимый консольный файловый менеджер Midnight Commander, клон Norton Commander -, не может перечислить (размер файла как 0 ), открыть или сделать что-либо с этим файлом:
Error
No such file or directory (2)
But I remembered that most Linux supports NTFS, whose maximum file name length is 255 UTF-16 characters.
Мы говорим о длине имени файла или о длине пути?
Максимальная длина пути NTFS всегда составляла 64 КБ (= 32 КБ UTF -16 кодовых точек ).
Win32 API налагал более строгие ограничения, потому что (редакционный комментарий )программисты-идиоты любили объявлять char filename[MAX_PATH], но вокруг этого были синтаксические ляпы.