Мне все еще кажется, что это, скорее всего, проблема ASCII или двоичного режима, несмотря на тест, который вы провели с вашим настольным клиентом. Ваш настольный клиент может быть умнее, чем FTP-клиент командной строки на отправляющем сервере (ваш локальный сервер, на котором вы запускаете свой скрипт).
Например, если локальным сервером является Windows (который использует CRLF в качестве конца строки), а удаленным сервером является Unix (который использует только LF в качестве окончания строки), и вы не указываете двоичный режим, а программное обеспечение FTP не выполняет автоматическое определите это и сделайте правильную вещь, тогда вы будете использовать режим ASCII для передачи, который должен лишить CR любых пар CRLF. Если в вашем архиве gzipped есть шаблон байтов 0x0d0a, который появится в любом месте, он потеряет 0x0d.
Если FTP-клиент командной строки в вашей отправляющей системе (я полагаю, это ваш локальный сервер) не похож на тот, который есть в моей системе, все, что вам нужно сделать, чтобы проверить эту теорию, это добавить binary команду до или после cd линия:
cd $FSBACKDIR
ATTACH='for file in *$DATE.tar.gz; do echo -n -e "put ${file}\n"; done'
ftp -nv <<EOF
open $FTPHOST
user $FTPUSER $FTPPASS
binary
cd $FTPDIR
$ATTACH
quit
EOF
Одна последняя мысль: если в конце концов это не ASCII или двоичный режим, я бы посмотрел, может ли FTP ALG в шлюзе NAT между вашим локальным и удаленным сервером (или между удаленным сервером и вашим рабочим столом) каким-то образом повредить файл в пути. Я полагаю, что между хостами может быть и другой вид прокси, а не FTP-ALG шлюза NAT.
