我不得不拆分这个2.6 GB的zip文件，以便通过缓慢的上行链路发送它。 我做到了这一点：
split -b 879m BIGFILE.zip 这创build了我上传到远程服务器的xaa，xab＆xac。 传输完成之后，我使用md5sum（在本地系统和服务器上）对这3个部分进行了validation：
md5sum xaa md5sum xab md5sum xab
所有的3个哈希值与我系统上的3个哈希值都是相同的，所以传输进行得很顺利。 现在，在远程系统上，当我这样做：
cat xa* > BIGFILE.zip
…然后我validation这个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 -l”时，它就可以工作。
谢谢你的帮助。 JFA
相同的MD5哈希表示转移运行良好。
超过2G的文件大小听起来像一些指针大小的问题 – 也许有问题的拉链处理不好？ 超过（ca）2G将是一个32位的负数…你可以解压缩在你压缩的系统上的文件？ 两个系统有什么不同？ 是一个64位，有问题的32位？ 两个系统上的文件系统是什么？ 你能find另一个压缩工具？
如果您有机会重新传输内容，则可能需要使用tar.gz或保持文件大小低于该值。 gzip压缩的内容应该处理这个更好。 Zip将内容（索引）存储在文件末尾。
编辑：是的， 看到这里 ：
实际上，由于UnZip使用fseek（）函数在档案中跳转，因此在许多系统上实际的限制可能是2 GB。 由于fseek的偏移量参数通常是一个带符号的长整数，因此在32位系统上，UnZip不会从档案开始find超过2 GB的任何文件[…]
你应该使用rsync来代替。 分裂是gheeetto。 这就是说我不知道你的问题有什么问题。 哦，等等…你现在可以使用rsync。 它只会传输文件之间的差异。 假设你在远程机器上有ssh访问权限：
rsync -Pvz BIGFILE.zip remotehostname:/path/to/BIGFILE.zip
…你完成了。
你是如何传输文件的？ 如果通过FTP进行ASCII模式将软pipe文件。 您可以使用解压缩的-F标志来纠正这个问题，但不要在这个标签上下注。
您可能需要重新传输文件 – 我build议通过scp来进行