Zstd: Différences entre gzip et zstd

Créé le 19 sept. 2017 · 4Commentaires · Source: facebook/zstd

zstd sous Linux: deux observations

1) Si je lance gzip pour compresser un gros fichier et si je tue gzip en utilisant ^C, gzip supprimera le fichier de sortie avant de se terminer. zstd ne le fait actuellement pas. Je pense que le comportement de gzip est meilleur, car il vaut mieux ne pas avoir de fichier de sortie que d'avoir un fichier de sortie incomplet ou corrompu.

2) Lors de la compression ou de la décompression d'un fichier, zstd utilise l'appel système ci-dessous pour créer le fichier de sortie (à partir de strace):
open("file.zst", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
gzip et xz utilisent des appels système similaires, mais ils utilisent le mode 0600. Ils basculent le mode du fichier de sortie vers le mode souhaité après la fermeture du fichier. Y a-t-il une raison pour laquelle zstd utilise 0666? Je pense que 0600 serait mieux: n'autorisez pas l'accès en lecture aux autres utilisateurs avant que le fichier ne soit prêt.

feature request question

Source

ghost

Tous les 4 commentaires

le piégeage de l'événement ^C nécessite un gestionnaire de signal. Je n'ai pas encore examiné la question. Je suis également préoccupé par les problèmes de portabilité.
Votre trace est plus précise que notre code.
L'appel pour ouvrir le fichier de destination est ici:
https://github.com/facebook/zstd/blob/dev/programs/fileio.c#L324
C'est juste un fopen("name", "wb"); standard, nous ne contrôlons aucun bit de propriété.
Cela se traduit par cette trace sur votre système, sachez simplement que nous n'avons pas de contrôle dessus.
De manière générale, nous essayons de rester le plus proche possible du standard C, pour des raisons de portabilité (et de réduction du casse-tête de dépendance).

Cyan4973 le 19 sept. 2017

Tout d'abord: merci d'avoir écrit zstd. Je suis étonné par la vitesse et le taux de compression! Très agréable!

N'hésitez pas à fermer ce ticket. Mes deux observations ne sont que des petites bribes et c'est parfaitement bien si vous décidez de ne rien faire.

Je suis d'accord que le piégeage ^C nécessite un gestionnaire de signal.
Intéressant. J'ai regardé dans le code source de xz et ils ouvrent le fichier de sortie avec le code ci-dessous:

      int flags = O_WRONLY | O_BINARY | O_NOCTTY | O_CREAT | O_EXCL;
      #ifndef TUKLIB_DOSLIKE
          flags |= O_NONBLOCK;
      #endif
      const mode_t mode = S_IRUSR | S_IWUSR;
      dest_fd = open( dest_name, flags, mode );

Ils utilisent open() au lieu de fopen() - et peuvent donc contrôler les bits d'autorisation du fichier de sortie.

ghost le 19 sept. 2017

👍1

Oui, je crois que xz cible les systèmes conformes aux POSIX ,
il peut donc utiliser librement les bibliothèques posix , au prix de ne pas être compatible avec les systèmes non posix ou de nécessiter des wrappers personnalisés (Windows vient à l'esprit).

zstd essaie autant que possible d'être standard-C , pour améliorer les perspectives de portabilité.

Techniquement, nous utilisons aussi occasionnellement des interfaces dépendant du système d'exploitation, lorsqu'il n'y a pas d'équivalent standard-C. Dans ce cas, nous essayons d'écrire plusieurs variantes pour prendre en charge plusieurs cibles, et pour celles qui ne le sont pas, les fonctionnalités pertinentes sont désactivées proprement (elles ont tendance à ne pas être essentielles).

Cyan4973 le 19 sept. 2017

Après en avoir appris un peu plus à ce sujet, il semble que la fonction signal() fait en fait partie du C standard , ce qui le rend assez bien portable.

Dans la dernière mise à jour de la branche dev , j'ai ajouté Ctrl-C trapping à zstd cli.
En appuyant sur Ctrl-C , il efface maintenant l'artefact d'opération (fichier de destination non terminé) avant de quitter.

Cyan4973 le 1 oct. 2017

❤1

Cette page vous a été utile?

0 / 5 - 0 notes