Rsync from Cifs to NTFS

[technotrance]

Здравствуйте!
Как и многие до этого, столкнулся с проблемой длинных имен файлов и каталогов в кириллице.
Итак, имеется следующее:
- Сервер Alt Linux 5.10.170-std-def-alt1
- Примонтированнаая виндовая шара через CIFS
- Отдельный диск под хранилище отформатированный в NTFS
- Скрипт, копирующий барахло из Cifs шары на диск NTFS
Вот сам скрипт (без воды):

Код: [Выделить]

# Поиск самой свежей копии TGN.
ActPathTGN="$(find /mnt/TGN-OTK -maxdepth 2 -name "TGN_*" | sed --regexp-extended 's/.*(..)\.(..)\.(....)$/\3-\2-\1\0/' | sort | tail -n 1 | cut -c 11-)"

# затягивание найденной копии к себе в хранилище.
rsync --bwlimit=38000 --log-file=/home/scripts/tgn-week.log -aq "$ActPathTGN" "/storage/TGN/"
Собственно, он ищет самую свежую папку, а-ля TGN_11.06.2023 и затягивает её к себе. А в этой папке немерено всякого файлового юзерского барахла. И очень много файлов с длинными именами.
Именно поэтому я и отформатировал диск в NTFS - на эту фс линукс позволяет записывать файлы с длинными именами, если это делать вручную. При отработке же скрипта у меня сыпятся уже знакомые ошибки:

Код: [Выделить]

rsync: [sender] send_files failed to open "/mnt/TGN-OTK/Z/TGN_11.06.2023/Контора/Служба продаж/Тендеры для заливки/БАЗА ТЕНДЕРОВ/82. Поставка (АГНКС) для объектов ООО Татнефть-АЗС Центр, ООО Татнефть-АЗС Запад/Макет условий договора о порядке приема-передачи выполненных работ (оказанных услуг), предоставлении первичных учетных документов и счетов-фактур (ЕРБ 287-2020).pdf": File name too long (36)
Однако! Если я вручную ввожу команду:

Код: [Выделить]

rsync --bwlimit=38000 --log-file=/home/scripts/tgn-week.log -aq "/mnt/TGN-OTK/Z/TGN_11.06.2023/Контора/Служба продаж/Тендеры для заливки/БАЗА ТЕНДЕРОВ/82. Поставка (АГНКС) для объектов ООО Татнефть-АЗС Центр, ООО Татнефть-АЗС Запад/Макет условий договора о порядке приема-передачи выполненных работ (оказанных услуг), предоставлении первичных учетных документов и счетов-фактур (ЕРБ 287-2020).pdf" "/storage/TGN/TGN_11.06.2023/Контора/Служба продаж/Тендеры для заливки/БАЗА ТЕНДЕРОВ/82. Поставка (АГНКС) для объектов ООО Татнефть-АЗС Центр, ООО Татнефть-АЗС Запад/"
то команда отрабатывает! Файл копируется. Почему? Ничего понять не могу. То ли скрипт у меня криво написан, то ли в другом месте криво С другой стороны, кривой скрипт вовсе бы не работал. Подскажите, куда копать?

[rits]

Команда tr -d [:cntrl:] позволяет удалить управляющие символы из переменной
Иногда при экспорте  могут попадать такие символы и usermod к примеру сыплет ошибки, может это как то и на rsync влияет, когда скрипт отрабатывает.
# байт в строке
echo "ф" | tr -d [:cntrl:] | wc -c

Код: [Выделить]

echo "Макет условий договора о порядке приема-передачи выполненных работ (оказанных услуг), предоставлении первичных учетных документов и счетов-фактур (ЕРБ 287-2020).pdf" | tr -d [:cntrl:] | wc -c
292
# Просмотреть список файлов и проверить на имена не более 255 байт
while read line; do len=`basename "$line" | tr -d [:cntrl:] | wc -c`; if [ $len -gt 255 ]; then echo $line; fi; done < path_1s.txt

Я думаю, копай в эту сторону. Кириллица занимает 2 байта на символ, а ext может только 255, а в кирилице (255/2), у тебя вроде ext-а нет, но может быть все-же управляющие символы попадают в переменные

[rits]

File name too long (36) - через гугл - Имя файла слишком длинное (36) 

[technotrance]

File name too long (36) - через гугл - Имя файла слишком длинное (36) 

Списибо, Кэп! А мужики то и не знали!©

[technotrance]

у тебя вроде ext-а нет, но может быть все-же управляющие символы попадают в переменные

Тоже об этом думал, попробую поработать с вашим вариантом

ext может только 255, а в кирилице (255/2)

Поэтому и решил попробовать NTFS

[kessys]

Ещё есть поверье что пробел microsoft может занимать 2 символа, а не 1. А вообще все длинные названия лучше укоротить

[technotrance]

Команда tr -d [:cntrl:] позволяет удалить управляющие символы из переменной

Добавил эту команду при задании переменной, получилось так:

ActPathTGN="$(find /mnt/TGN-OTK -maxdepth 2 -name "TGN_*" | sed --regexp-extended 's/.*(..)\.(..)\.(....)$/\3-\2-\1\0/' | sort | tail -n 1 | cut -c 11- | tr -d [:cntrl:])"

И наблюдение вот какое:
- Запускаю скрипт, и ошибки про длинные имена файлов всё равно вываливаются. Длинные файлы по-прежнему не копируются и пропускаются.
- Потом запускаю скрипт снова. Без каких-либо изменений и телодвижений. Просто запускаю его сразу снова. И уже ошибок про длинные имена нет. Все файлы с длинными именами он подтягивает к скопированным ранее.
Ну т.е. по факу получается, что при первом запуске скрипт затягивает все файлы, кроме длинных, а при втором запуске уже дотягивает оставшиеся длинные файлы.
Есть ли какие-то мысли о происходящем?

[rits]

Есть ли какие-то мысли о происходящем?

Я бы сначала, проанализировал длинные и короткие имена, и посмотрел бы разницу, почитал ман на  rsync и почитал, есть ли ограничения на длину пути к файлу. Также драйвер работы с NTFS под Linux может иначе отрабатывать, чем родной в Windows.
В любом случае,  с этими длинными файлами, надо какие то действия производить.

[technotrance]

Я бы сначала, проанализировал длинные и короткие имена, и посмотрел бы разницу

да собственно... А с какого боку подойти к их анализу? Файлы абсолютно разные могут быть: pdf-ки, doc, htm и прочие. Или это могут быть каталоги с длинными именами. Единственное, что в них общее - это длинные имена на кириллице, либо кириллице и латинице вместе.
В документации к rsync я не нашёл ничего на эту тему.

[rits]

А с какого боку подойти к их анализу?

Сравнить количество символов длинного имени "проблемных" и коротких файлов. Переименовать длинные и проверить на копирование. Проверить копирование "проблемных" файлов rsync-ом и cp-шкой, у них, как бы разный метод переноса данных.
Копировать на другие носители "проблемные" файлы.