Поврежденный zip-файл после использования split и cat в Linux

Мне пришлось разделить этот zip-файл на 2,6 ГБ, чтобы отправить его через медленный аплинк. Я сделал это:

split -b 879m BIGFILE.zip

Это создало xaa, xab и xac, которые я загрузил на удаленный сервер. После завершения передачи я проверил каждую из этих трех частей с помощью md5sum (как в моей локальной системе, так и на сервере):

md5sum xaa
md5sum xab
md5sum xab

Все 3 хэша были идентичны 3 хешам в моей системе, поэтому передача прошла успешно. Теперь, когда я делаю это в удаленной системе:

cat xa* > BIGFILE.zip

... затем я проверяю хэш этого BIGFILE.zip (в обеих системах):

md5sum BIGFILE.zip

... и они оба совпадают.

Теперь самое интересное. Когда я пытаюсь перечислить содержимое zip-файла, я получаю сообщение об ошибке:

unzip -l BIGFILE.zip

Я получил:

Archive:  BIGFILE.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of BIGFILE.zip or
        BIGFILE.zip.zip, and cannot find BIGFILE.zip.ZIP, period.

Это совершенно странно. Я использую одну и ту же версию "unzip" в обеих системах. Когда я использую "unzip -l" в моей локальной системе, это работает.

Спасибо за любую помощь. JFA

Идентичные хэши MD5 говорят о том, что передача прошла успешно.

Размер файла более 2 ГБ подозрительно похож на проблему с размером указателя - может быть, рассматриваемый zip не справляется с этим? более (приблизительно) 2G будет отрицательным числом в 32-битном формате ... Можете ли вы распаковать файл в системе, в которую вы его заархивировали? Обе системы различаются? Одна 64 битная, проблемная 32 битная? Каковы файловые системы в обеих системах? Сможете найти другую утилиту для архивирования файлов?

Если у вас есть возможность повторно передать контент, вы можете использовать tar.gz или оставить размер файла меньше этого значения. сжатый с помощью gzip контент должен справиться с этим лучше. Zip сохраняет содержимое (индекс) в конце файла.

Изменить: Ага, посмотреть здесь:

На практике реальный предел может составлять 2 ГБ во многих системах из-за того, что UnZip использует функцию fseek () для перемещения внутри архива. Поскольку аргумент смещения fseek обычно представляет собой длинное целое число со знаком, в 32-разрядных системах UnZip не найдет файл, размер которого превышает 2 ГБ от начала архива [...]

Как вы передавали файловые файлы? Если вы сделали это через FTP, в режиме ASCII файлы будут рассыпаны. Вы можете использовать флаг распаковки -F, чтобы исправить это, но не делайте ставки на это.

Возможно, вам придется повторно передать файлы - я бы рекомендовал сделать это через scp

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

rsync -Pvz BIGFILE.zip remotehostname:/path/to/BIGFILE.zip

... и вы сделали.