Неожиданные трудности взаимодействия между Windows и Linux в части сетевых папок

Неожиданные трудности взаимодействия между Windows и Linux в части сетевых папок Windows, Полезное, Помощник, Программное обеспечение, Linux, Поиск файлов, Скриншот

Как-то понадобилось мне скопировать терабайтную папку на 500 000 файлов на сервер-хранилку. Из них около 100 файлов наотрез отказались копироваться — оказалось, Linux не нравится, что имя файла длинное. А с виду так и не скажешь. А дело вот в чем.

В отличии от Linux, лимитирующей длину имен файлов и папок 255-ю байтами (файловая система ext4 и подобные), Windows в своей файловой системе NTFS ограничивает имена 255-ю двухбайтовыми символами в кодировке UTF-16. Набранные кириллицей имена в Windows могут быть длиной до 255 знаков, что невозможно в Linux, так как каждый символ кириллицы тоже будет занимать по два байта (в этой ОС обычно применяется кодировка UTF-8), быстро исчерпывая лимит.

Делюсь с вами написанной мною программой FindLongFilenamesLinux, которая и предназначена для поиска и переименования таких файлов и папок с именами, превышающими лимит, которые невозможно скопировать из Windows на NAS на основе Linux (с файловой системой ext4 и подобными). Мне это оказалось удобнее, чем каждый раз пробегаться по некопируемым файлам через Total Commander. Хотя тут кому как, лично мне не жаль было потратить на написание программы пару часов, зная, что подобная задачка с файлами встрянет еще не раз)

Для запуска программы требуется компонент .NET Framework 4.8+ (в актуальных билдах Win10/11 стоит по умолчанию, в Win7/8 устанавливается автоматически вместе с обновлениями).

Программа (Assets->FindLongFilenamesLinux.zip): https://github.com/carpediem-av/FindLongFilenamesLinux/releases

Исходный код (C#): https://github.com/carpediem-av/FindLongFilenamesLinux

Сайт автора: http://carpediem.0fees.us

Программы и Браузеры

481 пост5K подписчиков

Добавить пост

Правила сообщества

-Ставьте наши теги, если Ваш пост о программе, приложении или браузере(в том числе о расширениях, дополнениях в нему), его недоработке, баге, обновлении. Это может быть пост - обзор или отзыв.

-При возникновении споров относитесь с уважением друг к другу, а так же приводите аргументы.

Разрешено всё, что не запрещено правилами Пикабу.

9
Автор поста оценил этот комментарий

Уже видел комменты схожие, но у меня тоже возникли вопросы:

1) почему это не в виде скрипта? Бегло поискал, нашел примеры скриптов транслитерации, а обрезку по длине и сверку на коллизию обрезанных имён это достаточно просто сделать. Ваше решение пахнет оверинженирингом.

2) Я бы это всё оформил в виде вопроса и ответа на stackoverflow / habr qna, на Пикабу это никому не нужно, и никакой поисковик никак это решение не найдет.

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

1) Мне удобнее было так. И писать, и пользоваться потом. Почему другим неудобно - не знаю, может консоль больше любят, может думают если ".ехе" - то обязательно троян/вирус (хотя исходники я тоже выложил). Может думают, что реестр и систему "закакает" программа - тоже нет. Может у них семерки с выключенными обновлениями - ну, с Новым 2024 годом тогда вас еще разок. Ну а потом, если я хочу переименовать не автоматом, а сам осмысленно сократить имя - тут есть такая функция с подсчетом лимита. И длинные пути программа корректно понимает. И корректно такой файл покажет в Проводнике.

2) Я как-то больше люблю Пикабу)

показать ответы
Автор поста оценил этот комментарий
А вдруг кому из спецов попадётся на глаза мой вопрос)
Винда (7) подключенный в режиме обмена файлами телефон видит, а Тотал - нет. Можно ли его победить?
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

У себя проверил - Тотал видит. Даже старый фотик по USB видит (винда ему даже букву диска не присваивает - там свой протокол что ли). Версия 10.52 (х64, как и винда). Посмотрите, может у вас он просто староват.

Автор поста оценил этот комментарий

1 и кто там будет 259 символов делать у файла? =))))

2 это уже не простой юзверm imho

раскрыть ветку (1)
Автор поста оценил этот комментарий

1) Я выше уже писал, что винда выделяет больше байт под символы, 255 кириллических (которые по два байта занимают) там еще прокатит, а в линуксе - только 127 поместится. Уже не так и много. Чаще я это видел в файлах у юр. отдела - там любят документ обозвать подробно, указав даты, номера, содержание. И не хватает буквально нескольких байт лимита. У остальных это чаще были веб-странички сохраненные. Я вот эту страницу сейчас сохранил - имя файла на ~170 байт тянет, это еще название статьи короткое. Бухи так любят статьи про расчет НДС и прочего сохранить себе на всякий.

2) Кому-то просто знакомые айтишники настраивают и уходят. Как роутер например, его ж тоже не каждый простой юзер осилит настроить. Работает годами, ну, пока диски не сдохнут. А потом "вот тут у меня коробочка какая-то была, на ней файлы были..."

Автор поста оценил этот комментарий

хм =)))) простые юзеры с никсами и виндою? =))))


по мне так - если в теме и есть кроссы, то юзай латиницу и короткие название везде и будет щааастье =)

раскрыть ветку (1)
Автор поста оценил этот комментарий

Легко. Примеры:

1) предприятие с бухгалтерами, экономистами, инженерами и прочими простыми вин-юзерами. А файл-сервер админ запилил на никсах.

2) NAS типа "домашней" коробки Zyxel, QNAP и т.д., установленной простым юзером дома для хранения фото и видео. Там обычно ОС на основе никсов.


Обязать юзеров из первого примера юзать латиницу, сокращать имена - да проще уволиться сразу) Меня одна тетя (должность секретарь-референт), со стажем работы на ПК не менее 5 лет, однажды спросила "а как на рабочем столе создать папку?". Честно говоря, я от такого вопроса даже подзавис.

показать ответы
Автор поста оценил этот комментарий

ой, тупанул, сорян


тогда вопрос - но ведь переименование названия файла автоматически делает его "нерабочим"?  или тут речь не а прогах, а о доках?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Речь в основном о доках и простых юзерах. Программы пишут спецы и не раздувают имена файлов. Моя программа сохраняет расширение имени файла, поэтому он будет открываться нормально. Другое дело, когда на этот файл есть ссылки из других файлов (ну, например, книга Excel, на которую ссылается еще книга, или dwg + ссылочные картинки). Тогда автопереименование не годится, придется вручную, осмысленно + где надо потом править ссылки. В этой программе такое тоже есть.

показать ответы
Автор поста оценил этот комментарий

Если писать, то да, не вариант. Но это немного странный бэкап получается.

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Им еще и писать надо, файлы туда-сюда перетаскивать. Как быстро Тотал на лету перепаковывает терабайтные архивы? Я уже молчу, сколько открывается архив с таким кол-вом файлов, что в нем, что в винраре)

показать ответы
Автор поста оценил этот комментарий

*Открывает в тотал командере в левой панели виндовую машину с длинными именами.  В правой линуксовый сервер. Нажимает сделать архив из файлов в левой панели в правой панели. Наблюдает, как архив заливается на сервер со скоростью сети. Заходит в созданный архив тоталом. Видит все. Работает как с папкой.*


Коменты, прежде, чем написать, почитал.

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

показать ответы
Автор поста оценил этот комментарий

Вот же ж. И правда. Неожиданно. Оказывается 4096 — длина пути к файлу.

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


Видимо, если бы я столкнулся с идентичной ситуацией, логичнее было бы по быстрому замаунтить раздел c ntfs и не выёживаться с переименованиями.

В любом случае задачка интересная, а предложенное ТС-ом решение избыточно костыльное. Надо будет подумать когда мозг освободится от текущих задач.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Чего-то тут многие эти цифры между собой уже попутали, хм.

1
Автор поста оценил этот комментарий

он всё-таки для автоматизации, а не для написания программ)

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Да, да. "Вы не понимаете, это другое". Про HTML еще пойму)

2
Автор поста оценил этот комментарий

Я с таким столкнулся наоборот, в винде. Переустановил на одном компе десятку. Всё настроил, копирую файлы обратно на комп. И... Винда не приняла некоторые файлы, сказав, что, видите ли, имена слишком длинные. Запустил кубунту с лайва и всё нормально скопировал.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Тотал коммандер без проблем копирует, только спросит предварительно подтверждения. А вообще в винде для доступа к длинным путям в начало пути надо \\?\ писать.

4
Автор поста оценил этот комментарий

Причем тут Линукс, когда даже винда не всегда может работать с файлами созданными её же.

Часто пользователь сохраняя файлы в браузере не меняет имя на короткое,а если к этому добавить глубокую вложенность папок то вообще беда. Файлы открываются, а вот при переносе данных начинаются проблемы. Так что это не проблема Линукс... Проблема в именовании файлов самим пользователем. В 99 процентах случаев такие длинные имена самим пользователям не нужны, так как их никто читать не будет.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Окей. В корне диска на винде назовите любой файл максимально длинно кирилицей, попробуйте по сети на линь на ext4 скопировать. Потом отпишитесь, как прошло. Не даст он вам такое провернуть на своем поле (читай своей ФС).

4
Автор поста оценил этот комментарий

А Вы уверены что это проблема ext4 а не проблема samba или какой там ещё сервер используется для расшаривания дисков NAS-а в сеть? Просто, само по себе ограничение в 256 байт на длину всего пути при наличии ограничения в 4096 символов на длину имени файла выглядит крайне странно, а ext4 не дураки проектировали. А если это таки ограничение samba а не ext4 - возможно, стоило не имена файлов резать а залить их, например, через WinSCP, или, как тут уже советовали, запаковать сначала в архив?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Уверен. 255 байт лимит у ext4 и т.п. Самба не причем. На кириллице это чуть более 128 символов (если с пробелами и символами первой половины ASCII). Не, можно конечно NTFS юзать на лине и расшарить самбой, не будет такого лимита жесткого. Только это не очень верный подход)

1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

А кириллица еще и два байта в ext4 занимает, не забываем. А на вид имя не такое и длинное казалось бы.

21
Автор поста оценил этот комментарий

омг, один хочет перевести линукс на проприетарный HPFS (при наличии целого воза ФС для Linux), другой героически создает аналог Program Files, ТС пишет программу с функционалом однострочника на баше, которая тянет за собой целый Net Framework...

Иллюстрация к комментарию
раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Буду рад увидеть ваш однострочник на баше с ровно тем же функционалом. Но скорее всего не увижу. Net Framework не нужно тянуть, он и так предустановлен в актуальных виндах. Какой смысл отказываться от реально полезного фреймворка ради, видимо, предубеждений, совершенно необоснованных и непонятных мне? Еще моя программа тянет целую винду, о ней забыли упомянуть, ну это так, к слову)

показать ответы
1
Автор поста оценил этот комментарий

давно пора перевести линукс на HPFS, там на имя файла отведено 4 килобайта (4096 байт), а вместе с путем к файлу 64к (65535 байт).

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Тогда думаю, придется писать еще одну программу по типу "Поиск слишком длинных имен файлов для Windows"))))

показать ответы
2
Автор поста оценил этот комментарий

zfs уже придуман
только nas надо брать нормальный, а не уебанские коробки за штуку баксов без дисков с железом от бюджетного телефона

раскрыть ветку (1)
Автор поста оценил этот комментарий

и оперативка ему нужна ЕСС, обычная для этой ФС не рекомендуется.

показать ответы
1
Автор поста оценил этот комментарий
Хз, есть бесплатный тотал командер, который спокойно копирует даже самые длинные пути (у меня есть игруху как раз с такими путями и длинными названиями файлов)
раскрыть ветку (1)
Автор поста оценил этот комментарий

Ограничение сверху задано Линуксом, не поможет короче тотал тут.

показать ответы
2
Автор поста оценил этот комментарий

Ну, для меня тут на Линуксе аргумент "тянет целую винду" вполне актуален.
А похожий скрипт по транслитерации названий файлов туда и обратно я писал на питоне.

раскрыть ветку (1)
Автор поста оценил этот комментарий

На Линуксе описанной проблемы не будет, если вы конечно не будете файл, ранее записанный виндой на портативный диск в NTFS, копировать на самом Линуксе на его родные ФС.

2
Автор поста оценил этот комментарий

Я для этого много лет назад собрал генту с патчами под btrfs и ограничений на длину имён файлов не имею и везде под файловый сервер ставлю эту Вирт машину

раскрыть ветку (1)
Автор поста оценил этот комментарий

Кстати тоже вариант. Правда мало кто осилит генту)

10
Автор поста оценил этот комментарий

Была когда-то DOS, и все имена файлов помещались в 8.3. Теперь, гляди жь ты, 255 байт им не хватает. Что же это за имена файлов такие? "Жизнь, необыкновенные и удивительные приключения Робинзона Крузо, моряка из Йорка, прожившего двадцать восемь лет в полном одиночестве на необитаемом острове у берегов Америки близ устьев реки Ориноко, куда он был выброшен кораблекрушением, во время которого весь экипаж корабля, кроме него, погиб; с изложением его неожиданного освобождения пиратами. Написано им самим"?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну скачанные веб-страницы (ага, встречается еще) например, у них часто имена длинные. Сами пользователи любят подробно писать в имени все подряд. А вообще не так и много  это встречается - на 500 000 файлов нашел 100 таких.

7
Автор поста оценил этот комментарий

Речь не о длине имени файла, а о длине пути больше. Ext4 поддерживает имя файла до 4096 символов, но длина пути - 256. Т.е. там не так, как вы написали, а "users/local/config/CorpName/ProdName/appdata/main/something/ABCD/XYZ/somename/yas/conf.ini" на винде такие пути встречаются очень уж часто

раскрыть ветку (1)
Автор поста оценил этот комментарий

Вы ошибаетесь, все наоборот. 4096 - лимит длины пути. 255 байт - лимит на имя файла.

Автор поста оценил этот комментарий

штош, это будет первый гвоздичек в крышечку гробика виндовсика. )))

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Судя по тому, что я вижу, как люди спокойно переходят на 11-ю версию и местами некоторые даже нахваливают, гвоздей понадобится еще не меньше пары вагонов. Увы, Linux, увы, массовый юзер делает выбор раз за разом не в твою пользу(

Автор поста оценил этот комментарий

каким боком микрософт относится к HPFS?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну видимо, она разработана специалистами Microsoft (и IBM в том числе тоже), если wiki не врет.

показать ответы
6
Автор поста оценил этот комментарий

В нормальной локальной сети не должно быть случаев "коннект прерван"

В нормальной - да, просто у меня есть опыт, когда "нормальную" развернуть нет технической возможности. Рудодобывающие карьеры, раз в неделю мигрирующие вагончики-склады, территории по которым перемещаются самосвалы размером с пятиэтажку. В такой сети бывает всё построено на радиолинках, а там на соединение может повлиять погода, помехи, или мимо пробегающий медведь.

А про 1с вообще молчу, соединять их толстым клиентом - это как воду в решете носить, только терминал.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну в ненормальной сети значит, как тут предлагали, вариант с архивом. Или чуть ниже про rsync писали. Под каждую задачу, как говорится, найдется свой микроскоп инструмент

1
Автор поста оценил этот комментарий

Ты сам написал, быстрее и надежнее выходит. Может в конфигурации твой сети и нецелесообразно, не знаю. В целом идею имеет право на существование. Место да, больше. Небольшая проблема по-моему.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну я написал про доступ по FTP к файлам сайта, неявно подразумевая менее надежное соединение с удаленным сервером по Интернет с большой латентностью, в противовес локалке. Моя конфигурация и место действа - типовой офисный гигабит. Все компы/серваки в пределах здания/сегмента. Считай это как на внешний хард скопировать, скорость примерно плюс-минус будет, по опыту заметил.

Автор поста оценил этот комментарий

Чисто из академического интереса. создаем архив на винде, включающий длинное имя файла. Во время разархивирования на линукс, что станет с именем файла? Обрежется по максимальному лимиту? Или файл вообще будет скипнут? или разархивация встанет колом?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Зависит от программы-распаковщика. Скорее будет ошибка с указанием на проблемный файл. Если программа с GUI, может предложит продолжить с игнором (скипнуть). Само ничего не обрежется, это уже самоуправство будет)

6
Автор поста оценил этот комментарий

А зачем, если времени вагон, сеть стабильная, еще и гигабит между? Какой нибудь тотал коммандер, или фар, и вперед... Ты на архивацию и распаковку потратишь времени раза в 2 больше чем просто скопировать...

раскрыть ветку (1)
Автор поста оценил этот комментарий

Да. Поставил на ночь и забыл до утра. В моем случае еще предварительно проверил, чтобы не было длинных имен. Всё, утром файлы на серваке, юзеры довольны, админ спит до обеда)

5
Автор поста оценил этот комментарий

Ты кто? Архивируешь, копируешь архив, разархивируешь. Где в этой цепочке ты "потеряешь все"?

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

показать ответы
11
Автор поста оценил этот комментарий

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


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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

В нормальной локальной сети не должно быть случаев "коннект прерван". Если же они есть - думаю, админа ждут дела посерьезнее передачи вороха файлов) Про "коннект прерван", 1С и бухов вообще молчу - живьем съедят-с...

показать ответы
2
Автор поста оценил этот комментарий

А зачем, если времени вагон, сеть стабильная, еще и гигабит между? Какой нибудь тотал коммандер, или фар, и вперед...

Если

Ты на архивацию и распаковку потратишь времени раза в 2 больше чем просто скопировать...

Я ещё посмотрел, на сколько по времени отличается копирование одной длинной колбасы от  500000 файлов.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Сильно отличается, вот прям очень. Но ИМХО проще в одну операцию сделать, если времени вагон.

3
Автор поста оценил этот комментарий

А просто сценарий на bash не подошёл бы?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Посмотрел, что мне понадобится, чтобы запустить этот сценарий:

1) Установите WSL или Windows Subsystem для Linux.


Тогда уж давайте сценарий на PowerShell напишем, учитывая, с какой ОС и на какую копируются файлы. Ах, да, его еще и знать нужно)

С# + Visual Studio я уже знал.

показать ответы
2
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Если вы имели ввиду, что лучше писать без фреймворка, на голом С++/WinAPI или чистом javascript, или, или... Может где-то и лучше, но точно не быстрее, особенно если не готов вкладывать свое время в какую-нибудь мелочевку. Чтобы смотреть на программирование шире, нужно учить ASM, понимать как работает механизм предсказания ветвления, какие прерывания есть и зачем существуют и т.д и т.п., но правда тогда некогда будет программировать и создавать продукт. Можно даже попробовать написать свою операционку в учебных целях, как пробовал в студенчестве я. Смысл только, не факт что устроишься работать в нужное место.

7
Автор поста оценил этот комментарий

скопировать терабайтную папку на 500 000 файлов

И не запаковать ЭТО в архив? Кто ты?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Нужно было именно как есть разместить, никаких архивов. Так бывает) Кроме того, лично видел последствия, когда слегка битый архив (сетевая ошибка, бэдсектор, оперативка - да что угодно может "выстрелить") не распаковывался, итог - потеря всего (чаще всего этим грешит формат 7z кстати).

показать ответы