我正在开发一个存档大量带时间戳图像的系统。该系统的一部分是将图像保存到不断增长的 .zip 文件中。今天早上我注意到日志系统显示图像已成功下载并放置在 zip 文件中，但当我下载 .zip 文件时（从我们服务器上运行的 apache 别名中下载），图像与日志不匹配。例如，虽然日志显示相机 3484 于 2011 年 1 月 17 日拍摄，但当我从 apache 别名下载时，下载的 zip 文件仅包含截至 1 月 14 日的图像。
因此，我登录到服务器，将文件解压到其自己的目录中，该 zip 文件包含从 1 月 14 日到今天（1 月 17 日）的图像。让我感到奇怪的是，这应该与我从 apache 别名下载的文件完全相同。
其他实验：我将文件从服务器 scp 到本地计算机，zip 文件包含较新的图像。但是当我使用 SCP 客户端（在本例中为 OSX 版 Fugu）时，我得到的是较旧图像的 zip 文件。
简而言之：在服务器上解压文件或通过 scp 下载或通过 wget 下载后会生成一个 zip 文件，但从 Chrome、Firefox 或 SCP 客户端解压文件会生成一个不同的 zip 文件，而它们应该完全相同。
正在服务器上解压...
[user@server ~]$ cd /export1/amos/images/2011/84/3484/00003484/
[user@server 00003484]$ ls -la
total 6180
drwxr-sr-x 2 user groupname 24 Jan 17 11:20 .
drwxr-sr-x 4 user groupname 36 Jan 11 19:58 ..
-rw-r--r-- 1 user groupname 6309980 Jan 17 12:05 2011.01.zip
[user@server 00003484]$ unzip 2011.01.zip
Archive: 2011.01.zip
extracting: 20110114_140547.jpg
extracting: 20110114_143554.jpg
replace 20110114_143554.jpg? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
extracting: 20110114_143554.jpg
extracting: 20110114_153458.jpg
(...bunch of files...)
extracting: 20110117_170459.jpg
extracting: 20110117_173458.jpg
extracting: 20110117_180501.jpg
通过 apache 别名使用 wget。
local:~ user$ wget http://example.com/zipfiles/2011/84/3484/00003484/2011.01.zip
--12:38:13-- http://example.com/zipfiles/2011/84/3484/00003484/2011.01.zip
=> `2011.01.zip'
Resolving example.com... ip.ip.ip.ip
Connecting to example.com|ip.ip.ip.ip|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6,327,747 (6.0M) [application/zip]
100% [=====================================================================================================>] 6,327,747 1.03M/s ETA 00:00
12:38:56 (143.23 KB/s) - `2011.01.zip' saved [6327747/6327747]
local:~ user$ unzip 2011.01.zip
Archive: 2011.01.zip
extracting: 20110114_140547.jpg
(... same as before...)
extracting: 20110117_183459.jpg
使用 scp 获取 zip 文件
local:~ user$ scp user@server:/export1/amos/images/2011/84/3484/00003484/2011.01.zip .
2011.01.zip 100% 6179KB 475.3KB/s 00:13
local:~ user$ unzip 2011.01.zip
Archive: 2011.01.zip
extracting: 20110114_140547.jpg
(...same as before...)
extracting: 20110117_183459.jpg
使用 Fugu 从 /export1/amos/images/2011/84/3484/00003484/ 下载 2011.01.zip 可得到图像 20110113_090457.jpg 至 201100114_010554.jpg
使用 Firefox 从以下位置下载 2011.01.ziphttp://example.com/zipfiles/2011/84/3484/00003484/2011.01.zip给出图像 20110113_090457.jpg 至 201100114_010554.jpg
使用 Chrome 获得的结果与 Firefox 相同。
apache httpd.conf 中的相关部分：
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
Alias /zipfiles/ /export1/amos/images/
答案1
您提到的某些内容暗示 zip 文件在提供服务时被修改了。
您无法可靠地提供在请求过程中不断增大或截断的文件。显著缩短此窗口的理想方法是始终处理副本、编辑、rm 旧文件，然后将新文件 mv 到位（打开旧文件的进程继续提供它，在 mv“期间”检查的人会得到 404 并且至少知道要重试，之后的任何人都可以永久查看新文件。
否则，如果我对该语句理解过多，请尝试关闭 EnableSendfile。
答案2
我相信我已经明白了，我只是太傻了。
由于上周发生的错误（现已修复），有一段时间，一个 zip 文件可能被两个试图附加到同一文件的进程修改。因此，我认为由于某些 zip 文件并发问题，当两个进程都完成时，就会产生两个 zip 文件连接在一起的效果。而且，事实证明，不同的解压工具会查看这个怪兽的不同部分。因此，当我在服务器上使用 unzip 或使用 wget 后，它查看的是 zip 文件的一部分，而当我使用默认的 OSX GUI 工具解压时，它查看的是 zip 文件的另一部分。
下载一个.zip 文件并使用两个独立的工具可以验证这一理论。
抱歉，问题不是出在 Apache 上，正如我最初所想的那样。