Zenodo: Les fichiers gzippés sont compressés deux fois

Créé le 18 févr. 2019  ·  5Commentaires  ·  Source: zenodo/zenodo

Voir pour référence cet ensemble de données : https://zenodo.org/record/2539424

Il semble que Zenodo compresse les fichiers gzippés deux fois sans préavis. Ils sont donc "double compressés" (!). Ainsi, lorsque vous les téléchargez, ils doivent être nommés :

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

le truc super déroutant c'est que le MD5 affiché fait référence au fichier d'origine (compressé une fois) :

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

md5:2036a75ed53acdcc81f53061057fe343

cela ne correspond donc pas au fichier une fois que vous l'avez téléchargé, mais il correspond au fichier d'origine (compressé une seule fois).

Voilà donc ce que j'obtiens (j'enregistre le fichier téléchargé sous .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

Comme vous le voyez, le fichier téléchargé ne correspond pas au MD5 donné et si vous décompressez le fichier une fois, le MD5 correspond. Une fois décompressé, il correspond également aux sommes SHA512 que je fournis séparément dans le même jeu de données dans le fichier eswiki.wikilink_graph.sha512sums.txt :

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

C'est très étrange car Zenodo ne compresse pas les fichiers texte (le README et les fichiers de somme de hachage) et il n'y a aucun avis de ce comportement.


EDIT: Au cas où vous vous poseriez la question (puisque tout le monde à qui j'ai parlé de ce problème a posé la question), je suis sûr que les fichiers que j'ai téléchargés n'ont été compressés qu'une seule fois, je les ai sur mon disque, ils sont toujours là et ils sont compressés une fois .

Tous les 5 commentaires

Merci d'avoir signalé le problème.

J'ai reproduit le problème lié à l'en-tête Accept-Encoding: gzip envoyé par le navigateur.

$ 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

vs.

$ 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

J'étudie cela plus en profondeur, mais cela est soit lié à notre configuration NGINX, soit au type MIME fourni par notre serveur d'applications.

Ok, donc je pense que j'ai compris ce qui se passe. C'est une combinaison d'un bogue d'application et d'une mauvaise configuration.

Le type MIME est deviné par le serveur d'application de la manière suivante :

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

Cependant, il n'utilise que la première partie text/csv (le bogue). Par mesure de sécurité (car nous acceptons tous les fichiers téléchargés par les utilisateurs), le type mime est nettoyé avant d'être envoyé au navigateur, ce qui entraîne la conversion de $# text/csv en text/plain . NGINX voit alors un contenu d'en-tête text/plain , qu'il est configuré pour compresser avant de l'envoyer au client pour économiser de la bande passante (la mauvaise configuration).

Super! Faites-moi savoir si (et comment) je peux vous aider.

Malheureusement, une reconfiguration de NGINX n'a ​​pas réussi à résoudre le problème, il faudra donc un peu plus de temps pour le résoudre, car nous devons également corriger le bogue dans l'application. je

Cette page vous a été utile?
0 / 5 - 0 notes