场景：单个 1g CSV.gz 正在写入 FTP 文件夹。同时，我的客户端机器通过 sFTP 连接到该文件夹并尝试将其拉下。
问：在获取该文件后，无论我在客户端获得任何明显的长度，都可以gzip -t检测到部分文件并使部分文件失败，而不管截断在哪里？
我认为当片段突然结束时，解压缩或 -t'esting 会在 99% 的可能截断点上出错，但是 gz 结构是否有干净的切割点，gzip 会意外报告成功？
不在桌面上的缓解措施（因为如果其中一个在起作用，我不需要问上面的问题。）
- 通过另一个网络请求获取文件长度或 md5。
- 通过 FTP 轮询文件长度并不是很好，因为服务器可能会偶尔将块写入 zip 流。在批处理作业关闭文件句柄之前，将其误认为是完整的数据集对我的分析来说是致命的。
- 由批处理作业给出最终文件长度或散列消除了对这个 Q 的需要，但这给团队带来了实施负担，（对于这个 Q 的目的），可能不存在。
- 我们无法通过安排一天中不同时间的读/写来避免竞争。
- 服务器未使用原子移动操作。
- 我不知道 CSV 行/列计数；它会随着每个快照和每个集成而改变。也可以说被 gzip 压缩的文件是这个 Q 的不透明二进制 blob。
- 没有客户端=> sFTP 网络错误在起作用。（那些被捕获和处理；我担心的是读取一个在服务器批处理作业期间仍然偶尔写入的文件。）
- 使用 RESTful API 而不是 sFTP。
没有找到现有的 SO
一些 SO 涉及处理截断，但与需要在任何问题上可靠地使整个工作流程失败相比，它们处于有损可接受的上下文中。（我在医疗数据环境中进行计算，所以我宁愿让服务器停止并着火，也不愿传播不正确的统计数据。）
- gzip：文件意外结束 - 无论如何如何读取文件是相反的 - 他们希望抑制 EOF 错误，因为这对他们的用例来说不是问题
- 为什么在使用 gzip 时我的脚本中出现意外的文件结尾？只是 posix 流的结尾是故意插入的，
head并且没有涵盖“是否有可能出现误报？” - zcat / gzip error while pipe out is very close，但不问“我保证会得到这个错误吗？”
- 合并可能被截断的 gzipped 日志文件也很接近，因为它处理来自终止的批处理作业的部分文件，但仍然是丢弃一些不可读的行，而不是保证错误。