我正在研究一个系统，它可以对大量的时间戳图像进行归档。 系统的一部分涉及将图像保存到不断增长的.zip文件中。 今天早上我注意到，日志系统说，一个图像被成功下载并放置在zip文件中，但是当我下载.zip（来自运行在我们的服务器上的apache别名）时，图像与日志不匹配。 例如，尽pipe日志表示摄像机3484在2011年1月17日捕获，当我从apache别名下载时，下载的zip文件只包含截至1月14日的图像。
所以，我把它们放到服务器上，然后把文件解压缩到自己的目录下，那个zip文件从1月14日到今天（1月17日）都有图片。 令我感到奇怪的是，这应该与我从apache别名下载的文件完全相同。
其他实验：我从服务器上将文件scp-ed到我的本地机器，并且zip文件具有较新的图像。 但是当我使用一个SCP客户端（在这种情况下，为OSX Fugu），我得到了旧的图像的zip文件。
简而言之，解压缩服务器上的文件，或通过scp下载后或通过wget下载后提供一个zip文件，但从Chrome，Firefox或SCP客户端解压文件时，它们应该完全相同。
在服务器上解压缩…
[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从http://example.com/zipfiles/2011/84/3484/00003484/2011.01.zip下载2011.01.zip通过201100114_010554.jpg给出图像20110113_090457.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/
你提到的东西暗示着这个zip文件在服务的时候被修改了。
在请求过程中，您无法可靠地提供正在增长或截断的文件。 最好缩短这个窗口的理想方法是始终对旧文件进行复制，编辑，然后将新文件压缩到位（打开旧文件的进程继续提供服务，检查“执行期间”mv得到一个404，至less知道要重试，任何人都可以永久查看新文件。
否则，如果我读了太多的话，尝试closuresEnableSendfile。
我相信我明白了，我只是一个白痴。
由于上周发生了一个错误（这个问题已经被修复），有一段时间，一个zip文件可以被两个试图追加到同一个文件的进程修改。 所以，我相信由于一些zipfile并发问题，当两个进程完成后，它将两个zip文件连接在一起。 而且，事实certificate，不同的解压缩工具将看这个弗兰肯拉链怪物的不同部分。 所以，当我在服务器上使用unzip的时候，或者在使用wget之后，查看了压缩文件的一部分，而当我使用默认的OSX GUI工具来解压缩的时候，看到了zip文件的另一部分。
下载一个.zip文件并使用两个单独的工具validation这个理论。
对不起，这个问题不是关于Apache，正如我原先想的那样。