小编xan*_*der的帖子

场景：单个 1g CSV.gz 正在写入 FTP 文件夹。与此同时，我的客户端计算机通过 sFTP 连接到该文件夹​​并尝试将其拉下。

问：获取该文件后，无论我在客户端获得什么表观长度，都可以gzip -t检测到部分文件并使其失败，无论截断发生在何处？

我认为当片段突然结束时，解压缩或 -t'esting 将在 99% 的可能截断点上出错，但是 gz 结构是否具有干净的切割点，gzip 会在其中意外报告成功？

不在桌面上的缓解措施（因为如果其中之一正在发挥作用，我就不需要询问上述内容。）

1. 通过另一个网络请求获取文件长度或md5。
   1. 通过 FTP 轮询文件长度并不是很好，因为服务器可能会偶尔将块写入 zip 流。在批处理作业关闭文件句柄之前，如果将其误认为是完整的数据集，对我的分析来说将是致命的。
   2. 通过批处理作业给出最终文件长度或散列，就不再需要这个问题，但这给团队带来了实施负担，而团队（就这个问题而言）可能不存在。
2. 我们无法通过安排一天中不同时间的读/写来避免竞争。
3. 服务器未使用原子移动操作。
4. 我不知道 CSV 行/列数；每个快照和每个集成都会发生变化。对于这个问题，也可以说被 gzip 压缩的文件是一个不透明的二进制 blob。
5. 游戏中没有 client=>sFTP 网络错误。（这些被捕获并处理；我关心的是读取在服务器的批处理作业期间仍然偶尔写入的文件。）
6. 使用 RESTful API 代替 sFTP。

没有找到现有的SO

一些 SO 涉及处理截断，但与需要在任何问题上可靠地使整个工作流程失败相比，处于有损可接受的环境中。（我在医疗数据环境中进行计算，因此我宁愿让服务器停止并着火，也不愿传播错误的统计数据。）

• gzip：意外的文件结尾 - 如何读取文件是相反的 - 他们希望抑制 EOF 错误，因为这对他们的用例来说不是问题
• 为什么使用 gzip 时我的脚本中出现意外的文件结尾？只是 posix 流结尾有意插入，head并且不涵盖“是否有可能误报？”
• zcat / gzip 错误，同时管道输出 非常接近，但不会询问“我保证会收到此错误吗？”
• 合并可能被截断的 gzip 日志文件也很接近，因为它处理来自终止的批处理作业的部分文件，但仍然会抛出一些不可读的行，而不是保证错误。