Zstd: Diferencias entre gzip y zstd

Creado en 19 sept. 2017 · 4Comentarios · Fuente: facebook/zstd

zstd en Linux: dos observaciones

1) Si inicio gzip para comprimir un archivo grande y si elimino gzip usando ^ C, gzip eliminará el archivo de salida antes de terminar. zstd actualmente no hace eso. Creo que el comportamiento de gzip es mejor, porque es mejor no tener un archivo de salida que tener un archivo de salida incompleto o dañado.

2) Al comprimir o descomprimir un archivo, zstd usa la siguiente llamada al sistema para crear el archivo de salida (desde strace):
open("file.zst", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
gzip y xz usan llamadas de sistema similares, pero usan el modo 0600. Cambian el modo del archivo de salida al modo deseado después de cerrar el archivo. ¿Hay alguna razón por la que zstd usa 0666? Creo que 0600 sería mejor: no permita el acceso de lectura a otros usuarios antes de que el archivo esté listo.

feature request question

Fuente

ghost

Todos 4 comentarios

capturar el evento ^C requiere un controlador de señal. Aún no lo he investigado. También me preocupan los problemas de portabilidad.
Su rastreo es más preciso que nuestro código.
La llamada para abrir el archivo de destino está aquí:
https://github.com/facebook/zstd/blob/dev/programs/fileio.c#L324
Es solo un fopen("name", "wb"); estándar, no controlamos ningún bit de propiedad.
Sucede que se traduce en este rastro en su sistema, solo sepa que no tenemos control sobre él.
En general, tratamos de mantenernos lo más cerca posible del estándar C, por razones de portabilidad (y reducción del dolor de cabeza por dependencia).

Cyan4973 en 19 sept. 2017

En primer lugar: gracias por escribir zstd. ¡Estoy asombrado por la velocidad y la relación de compresión! ¡Muy agradable!

No dude en cerrar este ticket. Mis dos observaciones son solo pequeños detalles y está perfectamente bien si decides no hacer nada.

Estoy de acuerdo en que la captura de ^ C requiere un manejador de señales.
Interesante. Miré el código fuente de xz y abrieron el archivo de salida con el siguiente código:

      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 );

Usan open () en lugar de fopen () y, por lo tanto, pueden controlar los bits de permiso del archivo de salida.

ghost en 19 sept. 2017

👍1

Correcto, creo que xz apunta a sistemas compatibles con POSIX ,
por lo tanto, puede usar bibliotecas posix libremente, a costa de no ser compatible con sistemas que no son posix o de requerir envoltorios personalizados (me viene a la mente Windows).

zstd intenta ser estándar-C tanto como sea posible, para mejorar las perspectivas de portabilidad.

Técnicamente, también usamos ocasionalmente algunas interfaces dependientes del sistema operativo, cuando no hay un equivalente en C estándar. En tal caso, intentamos escribir varias variantes para admitir múltiples objetivos, y para los que no son compatibles, las funcionalidades relevantes se deshabilitan limpiamente (tienden a ser no esenciales).

Cyan4973 en 19 sept. 2017

Después de aprender un poco más al respecto, parece que la función signal() es en realidad parte del estándar C , lo que la hace bastante portátil.

En la última actualización de dev branch, agregué Ctrl-C trapping a zstd cli.
Al presionar Ctrl-C , ahora borra el artefacto de operación (archivo de destino sin terminar) antes de salir.

Cyan4973 en 1 oct. 2017

❤1

¿Fue útil esta página

0 / 5 - 0 calificaciones