Zenodo: Gzipped 文件被压缩两次

创建于 2019-02-18  ·  5评论  ·  资料来源: zenodo/zenodo

请参阅此数据集以供参考: https ://zenodo.org/record/2539424

Zenodo 似乎在没有通知的情况下将 gzip 压缩文件压缩了两次。 所以它们是“双重压缩的”(!)。 因此,当您下载它们时,它们应该被命名为:

eswiki.wikilink_graph.2006-03-01.csv.gz.gz

超级令人困惑的是显示的MD5是指原始文件(压缩一次):

eswiki.wikilink_graph.2006-03-01.csv.gz

md5:2036a75ed53acdcc81f53061057fe343

所以这与下载后的文件不匹配,但与原始文件匹配(仅压缩一次)。

这就是我得到的(我将下载的文件保存为.gz.gz ):

$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz.gz
b32c3b896be22c32bb17b9fe887bda51  eswiki.wikilink_graph.2006-03-01.csv.gz.gz

$ gunzip eswiki.wikilink_graph.2006-03-01.csv.gz.gz

$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz
2036a75ed53acdcc81f53061057fe343  eswiki.wikilink_graph.2006-03-01.csv.gz

$ sha512sum eswiki.wikilink_graph.2006-03-01.csv.gz
56a48b0f82922fee20c07b0a2480bca1872c5e4aa8521a86e178dc00aea5dd2e4cda4ae05eb1b1950da7447dae70d47d8daa8d7a3c62d6989aaad09bd1fbcc71
 eswiki.wikilink_graph.2006-03-01.csv.gz

$ zcat eswiki.wikilink_graph.2006-03-01.csv.gz | head -n10
page_id_from    page_title_from page_id_to  page_title_to
10  Argentina   3037    10 de enero
10  Argentina   3326    12 de octubre
10  Argentina   6301    13 de abril
10  Argentina   7874    1492
10  Argentina   6302    14 de abril
10  Argentina   14485   1502
10  Argentina   14471   1516
10  Argentina   14450   1536
10  Argentina   14434   1553

如您所见,下载的文件与给定的 MD5 不匹配,如果您解压缩文件一次,则 MD5 匹配。 解压缩后,它还与我在文件eswiki.wikilink_graph.sha512sums.txt的同一数据集中单独提供的 SHA512 总和匹配:

$ grep '2006-03-01' eswiki.wikilink_graph.sha512sums.txt
56a48b0f82922fee20c07b0a2480bca1872c5e4aa8521a86e178dc00aea5dd2e4cda4ae05eb1b1950da7447dae70d47d8daa8d7a3c62d6989aaad09bd1fbcc71
 eswiki.wikilink_graph.2006-03-01.csv.gz

这很奇怪,因为 Zenodo 没有压缩文本文件(README 和 hashsum 文件),并且在任何地方都没有注意到这种行为。


编辑:如果你想知道(因为我告诉过这个问题的每个人都问过)我确信我上传的文件只压缩了一次,我把它们放在我的磁盘上,它们仍然存在并且它们被压缩了一次.

所有5条评论

感谢您报告问题。

我已经重现了与浏览器发送的Accept-Encoding: gzip标头有关的问题。

$ curl -H "Accept-Encoding: gzip" -o eswiki.wikilink_graph.2006-03-01.csv.gz https://zenodo.org/record/2539424/files/eswiki.wikilink_graph.2006-03-01.csv.gz?download=1
$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz
b32c3b896be22c32bb17b9fe887bda51  eswiki.wikilink_graph.2006-03-01.csv.gz

对比

$ curl -o eswiki.wikilink_graph.2006-03-01.csv.gz https://zenodo.org/record/2539424/files/eswiki.wikilink_graph.2006-03-01.csv.gz?download=1
$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz
2036a75ed53acdcc81f53061057fe343  eswiki.wikilink_graph.2006-03-01.csv.gz

我正在进一步研究这个问题,但它要么与我们的 NGINX 配置有关,要么与我们的应用程序服务器提供的 MIMEtype 相关。

好的,所以我想我已经弄清楚发生了什么。 这是应用程序错误和配置错误的组合。

应用服务器猜测 MIME 类型类似于以下内容:

>>> import mimetypes
>>> mimetypes.guess_type('eswiki.wikilink_graph.2006-03-01.csv.gz')
('text/csv', 'gzip')

但是,它只使用第一部分text/csv (错误)。 作为一种安全措施(因为我们接受任何用户上传的文件),mimetype 在发送到浏览器之前会被清理,导致text/csv被转换为text/plain 。 NGINX 然后会看到一个text/plain标头内容,它被配置为在发送到客户端之前对其进行压缩以节省带宽(配置错误)。

伟大的! 让我知道是否(以及如何)我可以提供帮助。

不幸的是,重新配置 NGINX 并没有解决问题,因此修复它需要更长的时间,因为我们还需要修复应用程序中的错误。 一世

关闭: https ://github.com/inveniosoftware/invenio-files-rest/pull/202

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

slint picture slint  ·  4评论

noamross picture noamross  ·  8评论

lnielsen picture lnielsen  ·  8评论

maurice-schleussinger picture maurice-schleussinger  ·  3评论

bniebuhr picture bniebuhr  ·  6评论