[opensuse-es] Extracción de datos desde un archivador "tar.gz" >3 GB.
Hola, Estoy intentando rescatar de un archivador que tengo (creado con tar) un documento de la copia de seguridad, pero al restaurarlo el archivo está corrupto. De hecho, todos los archivos que tengo dentro del tar.gz se restauran mal. Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar). ¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro? Estoy con openSUSE 10.3 y el formato de la partición de backup es ext3. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/9/1 Camaleón
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller)
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
mmm, tengo entendido que no hay limitación de tamaño en gzip. Si con tar, que es 2^63-1 y 8^12-1 por cada archivo que contenga. Un tar.gz no es más que un tar comprimido con gzip. Te da algún error al descomprimir con gunzip ? digamos un "unexpected end of file"? Podrías intentar algo así: gunzip < archivo.tar.gz > archivoparcial.tar y luego ve si puedes abrir el .tar creado. -- Kind Regards -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
2009/9/1 Camaleón:
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller)
Dejo esta opción para el final :-)
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
mmm, tengo entendido que no hay limitación de tamaño en gzip. Si con tar, que es 2^63-1 y 8^12-1 por cada archivo que contenga. Un tar.gz no es más que un tar comprimido con gzip.
Te da algún error al descomprimir con gunzip ? digamos un "unexpected end of file"?
No, ningún error. Desde el MC hago la copia del archivo sin problemas pero parece que el archivo restaurado está en formato ascii en lugar de binario. Por ejemplo, un .odt lo abro y veo sólo bloques de texto. Una imagen... y lo mismo. *** hpc02@stthpc:~/Desktop> file imagen.jpg imagen.jpg: ASCII text Cuando la original es: hpc02@stthpc:~/Desktop/> file imagen_orig.jpg imagen_orig.jpg: JPEG image data, JFIF standard 1.00, comment: "LEAD Technologies Inc. V1.01" ***
Podrías intentar algo así:
gunzip < archivo.tar.gz > archivoparcial.tar
Tras 5 minutos descomprimiendo...
y luego ve si puedes abrir el .tar creado.
...genera un tar de 5 GB. Accedo igualmente con MC y copio el archivo al escritorio pero el formato sigue "corrupto" :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-01 a las 21:39 +0200, Camaleón escribió:
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
Te da algún error al descomprimir con gunzip ? digamos un "unexpected end of file"?
No, ningún error. Desde el MC hago la copia del archivo sin problemas pero parece que el archivo restaurado está en formato ascii en lugar de binario. Por ejemplo, un .odt lo abro y veo sólo bloques de texto. Una imagen... y lo mismo.
*** hpc02@stthpc:~/Desktop> file imagen.jpg imagen.jpg: ASCII text
Cuando la original es:
hpc02@stthpc:~/Desktop/> file imagen_orig.jpg imagen_orig.jpg: JPEG image data, JFIF standard 1.00, comment: "LEAD Technologies Inc. V1.01" ***
Bueno... yo he dicho otras veces que el tgz es un mal formato para hacer backups, y ahí tienes la prueba. Si hay un error en la compresión, todo el archivador queda afectado. El zip es más robusto. O el rar, creo. Algunas herramientas usan cpio, comprimiendo fichero por fichero, no el archivador entero, con lo que el daño sería reducido. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqdocsACgkQtTMYHG2NR9XWbQCeP7S6xzxMj1MQ070YSilqzyVP FwYAnjKOoiO2JDZaBB2LsEnnrsFP3v/5 =/wOl -----END PGP SIGNATURE-----
El 2009-09-02 a las 00:35 +0200, Carlos E. R. escribió:
El 2009-09-01 a las 21:39 +0200, Camaleón escribió:
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
Te da algún error al descomprimir con gunzip ? digamos un "unexpected end of file"?
No, ningún error. Desde el MC hago la copia del archivo sin problemas pero parece que el archivo restaurado está en formato ascii en lugar de binario. Por ejemplo, un .odt lo abro y veo sólo bloques de texto. Una imagen... y lo mismo.
*** hpc02@stthpc:~/Desktop> file imagen.jpg imagen.jpg: ASCII text
Cuando la original es:
hpc02@stthpc:~/Desktop/> file imagen_orig.jpg imagen_orig.jpg: JPEG image data, JFIF standard 1.00, comment: "LEAD Technologies Inc. V1.01" ***
Bueno... yo he dicho otras veces que el tgz es un mal formato para hacer backups, y ahí tienes la prueba. Si hay un error en la compresión, todo el archivador queda afectado.
Pero no está corrupto. La verdad es que no sé qué pasa :-?
El zip es más robusto. O el rar, creo.
El zip tiene la limitación de los 4 GB y el rar es un formato propietario que nunca me ha terminado de gustar :-/
Algunas herramientas usan cpio, comprimiendo fichero por fichero, no el archivador entero, con lo que el daño sería reducido.
No sé, ya digo que no sé qué es lo que ha podido pasar, pero no creo que esté corrupto. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-02 a las 13:22 +0200, Camaleón escribió:
El 2009-09-02 a las 00:35 +0200, Carlos E. R. escribió:
Bueno... yo he dicho otras veces que el tgz es un mal formato para hacer backups, y ahí tienes la prueba. Si hay un error en la compresión, todo el archivador queda afectado.
Pero no está corrupto. La verdad es que no sé qué pasa :-?
El zip es más robusto. O el rar, creo.
El zip tiene la limitación de los 4 GB y el rar es un formato propietario que nunca me ha terminado de gustar :-/
No se si el zip sigue teniendo esa limitación. ¿Por archivo o por fichero? De todos modos, son formatos más robustos para backups que el tgz. No: The original ZIP format had a 4GB limit on various things (uncompressed size of a file, compressed size of a file and total size of the archive), as well as a limit of 65535 entries in a zip archive. In version 4.5 of the specification (which is not the same as v4.5 of any particular tool), PKWARE introduced the "ZIP64" format extensions to get around these limitations. Zip64 support is emerging. For example, the File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista does. Likewise - some libraries, such as IO::Compress::Zip in Perl, have new support for ZIP64, while others, such as Java's built-in java.util.zip, still lack it. http://en.wikipedia.org/wiki/ZIP_(file_format) Falta saber si la versión de linux soporta zip64, porque sé que la siguiente caraterística no la soporta (si no han cambiado): The ZIP spec also supports spreading archives across multiple filesystem files. Originally intended for storage of large zip files across multiple 1.44mb floppy disks, this feature is now used for sending zip archives in parts over email, or over other transports or removable media). El zip de linux parte sólo al final de fichero: es una limitación importante, si no la han resuelto. Esto es importante: The Info-ZIP implementations also know how to use the error correction capabilities built into the ZIP compression format. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqeyh8ACgkQtTMYHG2NR9XOYgCgmQFEGIs4FAtqVWRkLy5t/kR6 y8MAnRk05wMrFaSQfL+3wqi9lQihx2Iu =SuQx -----END PGP SIGNATURE-----
El 2009-09-02 a las 21:40 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 13:22 +0200, Camaleón escribió:
El 2009-09-02 a las 00:35 +0200, Carlos E. R. escribió:
Bueno... yo he dicho otras veces que el tgz es un mal formato para hacer backups, y ahí tienes la prueba. Si hay un error en la compresión, todo el archivador queda afectado.
Pero no está corrupto. La verdad es que no sé qué pasa :-?
El zip es más robusto. O el rar, creo.
El zip tiene la limitación de los 4 GB y el rar es un formato propietario que nunca me ha terminado de gustar :-/
No se si el zip sigue teniendo esa limitación. ¿Por archivo o por fichero? De todos modos, son formatos más robustos para backups que el tgz.
No lo sé, pero sí recordaba perfectamente este hilo: [opensuse-es] ¿Con que se descomprime un zip de 5,5GB? http://lists.opensuse.org/opensuse-es/2009-02/msg00982.html Y la verdad es que para copias de seguridad prefiero utilizar un método lo maś normalizado posible, para evitar posibles incompatibilidades, es decir, que pueda tener acceso a esa copia desde cualquier sistema o entorno sin necesidad de tener instalado algún programa o biblioteca en concreto. De hecho, dejé de usar en suse un programita en java para hacer las copias de seguridad y me pasé al "tar" porque en una de las actualizaciones del programa se hacían incompatibles los archivos generados con versiones anteriores del mismo (no podías leerlos ni acceder a los datos), por lo que te obligaba a rehacer de nuevo las copias, lo cual me parece una barbaridad y, obviamente, poco serio :-( El rsync para backup no me termina de convencer y al final me decanté por la opción más sencilla para generar los archivadores y para recuperar los datos... o eso pensaba, vaya >:-)
No:
The original ZIP format had a 4GB limit on various things (uncompressed size of a file, compressed size of a file and total size of the archive), as well as a limit of 65535 entries in a zip archive. In version 4.5 of the specification (which is not the same as v4.5 of any particular tool), PKWARE introduced the "ZIP64" format extensions to get around these limitations. Zip64 support is emerging. For example, the File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista does. Likewise - some libraries, such as IO::Compress::Zip in Perl, have new support for ZIP64, while others, such as Java's built-in java.util.zip, still lack it.
http://en.wikipedia.org/wiki/ZIP_(file_format)
Falta saber si la versión de linux soporta zip64, porque sé que la siguiente caraterística no la soporta (si no han cambiado):
The ZIP spec also supports spreading archives across multiple filesystem files. Originally intended for storage of large zip files across multiple 1.44mb floppy disks, this feature is now used for sending zip archives in parts over email, or over other transports or removable media).
El zip de linux parte sólo al final de fichero: es una limitación importante, si no la han resuelto.
Esto es importante:
The Info-ZIP implementations also know how to use the error correction capabilities built into the ZIP compression format.
El Zip64 aún no está muy extendido. Y teniendo suses 10.3 y windows XP en la oficina su uso no me parecía lo más adecuado. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-02 a las 22:48 +0200, Camaleón escribió:
El 2009-09-02 a las 21:40 +0200, Carlos E. R. escribió:
No lo sé, pero sí recordaba perfectamente este hilo:
[opensuse-es] ¿Con que se descomprime un zip de 5,5GB? http://lists.opensuse.org/opensuse-es/2009-02/msg00982.html
Ah, se me habia olvidado. Por cierto, ahi se dijo que el soporte de zip64 viene en el unzip version 5.60, pero tanto la 11.0 como la 11.1 tienen la 5.52.
Y la verdad es que para copias de seguridad prefiero utilizar un método lo maś normalizado posible, para evitar posibles incompatibilidades, es decir, que pueda tener acceso a esa copia desde cualquier sistema o entorno sin necesidad de tener instalado algún programa o biblioteca en concreto.
Si no necesitas tamaños tan grandes, el zip es un formato estandard que funciona en muchos sistemas. Tan estandard como el tar, y con varios "proveedores".
De hecho, dejé de usar en suse un programita en java para hacer las copias de seguridad y me pasé al "tar" porque en una de las actualizaciones del programa se hacían incompatibles los archivos generados con versiones anteriores del mismo (no podías leerlos ni acceder a los datos), por lo que te obligaba a rehacer de nuevo las copias, lo cual me parece una barbaridad y, obviamente, poco serio :-(
Yo no uso tar para backups porque es propenso a fallos, no es robusto. No es cuestión de la implementación, es el propio formato. Lo acabas de ver en tus carnes, el software no ha sido capaz de distinguir por sus propios medios que no lo habías comprimido con gzip sino con bzip2. El problema es que el tar no tiene compresión interna, ni es parte de su estructura o formato.
El rsync para backup no me termina de convencer y al final me decanté por la opción más sencilla para generar los archivadores y para recuperar los datos... o eso pensaba, vaya >:-)
El rsync es robusto, pero genera una copia fichero a fichero, y sin comprimir.
El Zip64 aún no está muy extendido. Y teniendo suses 10.3 y windows XP en la oficina su uso no me parecía lo más adecuado.
El 64 no, porque no está extendido. El zip normal, sí. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqe9PIACgkQtTMYHG2NR9V1LwCeIndgxXysC3VlPXJ8o+PUSBwV 3g8An0gaXgebDQj5Nk2IPFSBQ8D3HmXI =GIq4 -----END PGP SIGNATURE-----
El 2009-09-03 a las 00:42 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 22:48 +0200, Camaleón escribió:
El 2009-09-02 a las 21:40 +0200, Carlos E. R. escribió:
No lo sé, pero sí recordaba perfectamente este hilo:
[opensuse-es] ¿Con que se descomprime un zip de 5,5GB? http://lists.opensuse.org/opensuse-es/2009-02/msg00982.html
Ah, se me habia olvidado. Por cierto, ahi se dijo que el soporte de zip64 viene en el unzip version 5.60, pero tanto la 11.0 como la 11.1 tienen la 5.52.
Lo cual es una desventaja :-(
Y la verdad es que para copias de seguridad prefiero utilizar un método lo maś normalizado posible, para evitar posibles incompatibilidades, es decir, que pueda tener acceso a esa copia desde cualquier sistema o entorno sin necesidad de tener instalado algún programa o biblioteca en concreto.
Si no necesitas tamaños tan grandes, el zip es un formato estandard que funciona en muchos sistemas. Tan estandard como el tar, y con varios "proveedores".
El zip es que uso habitualmente pero para backup me no sirve, hay que usar el zip64 y es un handicap.
De hecho, dejé de usar en suse un programita en java para hacer las copias de seguridad y me pasé al "tar" porque en una de las actualizaciones del programa se hacían incompatibles los archivos generados con versiones anteriores del mismo (no podías leerlos ni acceder a los datos), por lo que te obligaba a rehacer de nuevo las copias, lo cual me parece una barbaridad y, obviamente, poco serio :-(
Yo no uso tar para backups porque es propenso a fallos, no es robusto. No es cuestión de la implementación, es el propio formato. Lo acabas de ver en tus carnes, el software no ha sido capaz de distinguir por sus propios medios que no lo habías comprimido con gzip sino con bzip2.
Al tar no creo que le haya pasado nada en este caso. Es el MC el que ha fallado :-(
El problema es que el tar no tiene compresión interna, ni es parte de su estructura o formato.
Admito sugerencias, teniendo en cuenta las necesidades citadas previamente :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-03 a las 08:20 +0200, Camaleón escribió:
El 2009-09-03 a las 00:42 +0200, Carlos E. R. escribió:
[opensuse-es] ¿Con que se descomprime un zip de 5,5GB? http://lists.opensuse.org/opensuse-es/2009-02/msg00982.html
Ah, se me habia olvidado. Por cierto, ahi se dijo que el soporte de zip64 viene en el unzip version 5.60, pero tanto la 11.0 como la 11.1 tienen la 5.52.
Lo cual es una desventaja :-(
Cierto.
Y la verdad es que para copias de seguridad prefiero utilizar un método lo maś normalizado posible, para evitar posibles incompatibilidades, es decir, que pueda tener acceso a esa copia desde cualquier sistema o entorno sin necesidad de tener instalado algún programa o biblioteca en concreto.
Si no necesitas tamaños tan grandes, el zip es un formato estandard que funciona en muchos sistemas. Tan estandard como el tar, y con varios "proveedores".
El zip es que uso habitualmente pero para backup me no sirve, hay que usar el zip64 y es un handicap.
Es verdad.
De hecho, dejé de usar en suse un programita en java para hacer las copias de seguridad y me pasé al "tar" porque en una de las actualizaciones del programa se hacían incompatibles los archivos generados con versiones anteriores del mismo (no podías leerlos ni acceder a los datos), por lo que te obligaba a rehacer de nuevo las copias, lo cual me parece una barbaridad y, obviamente, poco serio :-(
Yo no uso tar para backups porque es propenso a fallos, no es robusto. No es cuestión de la implementación, es el propio formato. Lo acabas de ver en tus carnes, el software no ha sido capaz de distinguir por sus propios medios que no lo habías comprimido con gzip sino con bzip2.
Al tar no creo que le haya pasado nada en este caso. Es el MC el que ha fallado :-(
Pero no hubiera fallado si el formato incluyera las salvaguardas del zip.
El problema es que el tar no tiene compresión interna, ni es parte de su estructura o formato.
Admito sugerencias, teniendo en cuenta las necesidades citadas previamente :-)
Ya... es que es un problema. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqgJJIACgkQtTMYHG2NR9U0wgCfcUtMlxfaWIojAI/jMwwQKD4K Y7UAn0pqJOcEJK0wxsoBW55gAtt5lwr5 =gNNq -----END PGP SIGNATURE-----
On Tuesday 01 September 2009 21:39:50 Camaleón wrote:
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
2009/9/1 Camaleón:
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller)
Dejo esta opción para el final :-)
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
mmm, tengo entendido que no hay limitación de tamaño en gzip. Si con tar, que es 2^63-1 y 8^12-1 por cada archivo que contenga. Un tar.gz no es más que un tar comprimido con gzip.
Te da algún error al descomprimir con gunzip ? digamos un "unexpected end of file"?
No, ningún error. Desde el MC hago la copia del archivo sin problemas pero parece que el archivo restaurado está en formato ascii en lugar de binario. Por ejemplo, un .odt lo abro y veo sólo bloques de texto. Una imagen... y lo mismo.
pasale el uudecode a ver que saca -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 08:30 +0200, francisco f escribió:
On Tuesday 01 September 2009 21:39:50 Camaleón wrote:
Te da algún error al descomprimir con gunzip ? digamos un "unexpected end of file"?
No, ningún error. Desde el MC hago la copia del archivo sin problemas pero parece que el archivo restaurado está en formato ascii en lugar de binario. Por ejemplo, un .odt lo abro y veo sólo bloques de texto. Una imagen... y lo mismo.
pasale el uudecode a ver que saca
Me saca un error "No hay línea `begin'" :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-01 a las 21:39 +0200, Camaleón escribió:
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
2009/9/1 Camaleón:
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller)
Dejo esta opción para el final :-)
Puf. Este programita ha podido extraer el archivo que necesitaba. Nada grave, sólo era un documento de fax en formato .odt que ayer sobreescribí por error, pero al ver el panorama que se me había presentado al restaurar los archivos, por un momento "se me habían puesto de corbata" (*) pensando que el resto de copias archivadas de backup estarían igual :-} Gracias Gabriel. (*) Ponerse de corbata: dícese de cuando los archivadores que se tienen almacenados se restauran en formato ASCII y se pasa un trago muuuy largo y muuuuy malo. P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/9/2 Camaleón
Puf. Este programita ha podido extraer el archivo que necesitaba.
Nada grave, sólo era un documento de fax en formato .odt que ayer sobreescribí por error, pero al ver el panorama que se me había presentado al restaurar los archivos, por un momento "se me habían puesto de corbata" (*) pensando que el resto de copias archivadas de backup estarían igual :-}
Gracias Gabriel.
Bueno, me alegro.
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
Buena pregunta. -- Kind Regards -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 02 September 2009 17:20:48 Camaleón wrote:
El 2009-09-01 a las 21:39 +0200, Camaleón escribió:
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
2009/9/1 Camaleón:
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller)
Dejo esta opción para el final :-)
Puf. Este programita ha podido extraer el archivo que necesitaba.
¿Por qué no has hecho un: ? tar xjvf archivo.tar.bz2 nom_fich_extraer.ext Esto te permite extraer sólo aquel fichero que quieres extraer y te lo deja en el directorio en el que estás (PWD).
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
NPI, no uso el MC. Me imagino que tendrá alguna configuración por ahí. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 17:40 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 17:20:48 Camaleón wrote:
Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller)
Dejo esta opción para el final :-)
Puf. Este programita ha podido extraer el archivo que necesitaba.
¿Por qué no has hecho un: ?
tar xjvf archivo.tar.bz2 nom_fich_extraer.ext
Esto te permite extraer sólo aquel fichero que quieres extraer y te lo deja en el directorio en el que estás (PWD).
Estoy acostumbrada al Midnight Commander, por eso he tirado de él, como siempre... navego hasta el archivo que quiero restaurar y lo copio al escritorio. Ni por un momento pensé que iba a hacer esa trastada, de hecho no es la primera vez que restauro archivos desde archivadores de gran tamaño y no había tenido este problema. Por eso pensé que podría tener relación con el tamaño del archivo :-?
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
NPI, no uso el MC. Me imagino que tendrá alguna configuración por ahí.
-10 puntos para él (-5 por fallar y -5 por el susto :-P). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-09-01 a las 21:39 +0200, Camaleón escribió:
El 2009-09-01 a las 16:11 -0300, Gabriel escribió:
2009/9/1 Camaleón:
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar). Si probás con xarchiver? es más rápido que los otros frontends (ark, file-roller) Dejo esta opción para el final :-)
Puf. Este programita ha podido extraer el archivo que necesitaba.
Nada grave, sólo era un documento de fax en formato .odt que ayer sobreescribí por error, pero al ver el panorama que se me había presentado al restaurar los archivos, por un momento "se me habían puesto de corbata" (*) pensando que el resto de copias archivadas de backup estarían igual :-}
Gracias Gabriel.
(*) Ponerse de corbata: dícese de cuando los archivadores que se tienen almacenados se restauran en formato ASCII y se pasa un trago muuuy largo y muuuuy malo.
Como eres mujer, lo has explicado muy mal lo de la corbata. Los hombres lo entendemos con una sencilla explicación de dos palabras... sólo que como hay señoritas pora aquí, no la voy a poner :)
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
Pos no sé, Camaleón. Pero me parece un error usar clones DOS en linux para cosas críticas o de bajo nivel. Y el Mignight Commander es un clon de Norton.
Saludos,
-- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 17:59 +0200, César Alonso escribió:
Camaleón escribió:
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
Pos no sé, Camaleón. Pero me parece un error usar clones DOS en linux para cosas críticas o de bajo nivel. Y el Mignight Commander es un clon de Norton.
¿No querrás que use Minix o Unix en lugar de Linux? Digo, para usar el original y no estar trabajando con "clones" >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-09-02 a las 17:59 +0200, César Alonso escribió:
Camaleón escribió:
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
Pos no sé, Camaleón. Pero me parece un error usar clones DOS en linux para cosas críticas o de bajo nivel. Y el Mignight Commander es un clon de Norton.
¿No querrás que use Minix o Unix en lugar de Linux? Digo, para usar el original y no estar trabajando con "clones" >:-)
No hombre, no, no me enredes... que me has entendido perfectamente. :P
Saludos,
-- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-02 a las 17:20 +0200, Camaleón escribió:
P.S. ¿Qué "¡=?*&%·#@@!" demonios le pasa al Midnight Commander? ¿Por qué hace semejante barbaridad con los archivos? >}:-?
Hay un bug, que creo reporté, que sucede cuando abres un archivador, y después abres otro del mismo nombre, pero distinto: se cree que es el mismo, y en realidad abre el temporal expandido que todavía no ha borrado del anterior. Si se sospecha eso, basta con salir y volver a entrar para resetearlo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqexwgACgkQtTMYHG2NR9UBegCeLyiT8gC5N/aunMogQBdDPOaU ecsAn2X6kEkDcsXgkRIJM+Mg1o/3UuWd =L2lS -----END PGP SIGNATURE-----
El 01/09/09, Camaleón
Hola,
Estoy intentando rescatar de un archivador que tengo (creado con tar) un documento de la copia de seguridad, pero al restaurarlo el archivo está corrupto. De hecho, todos los archivos que tengo dentro del tar.gz se restauran mal.
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
Buscando un poco sobre tu problema me fui a encontrar con este hilo que discutieron hace un par de años. http://lists.opensuse.org/opensuse-es/2007-09/msg00453.html Solo es un recordatorio, ya que no veo porque los recupera corruptos (solo que este dañado todo el .tar.gz)
Estoy con openSUSE 10.3 y el formato de la partición de backup es ext3.
Saludos,
-- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Linux codigo abierto: Millones de personas en el mundo con mentes abiertas no pueden estar equivocadas -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-01 a las 15:54 -0600, cheperobert escribió:
El 01/09/09, Camaleón escribió:
(...)
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
Buscando un poco sobre tu problema me fui a encontrar con este hilo que discutieron hace un par de años.
Eso es "puntería" >:-)
Solo es un recordatorio, ya que no veo porque los recupera corruptos (solo que este dañado todo el .tar.gz)
El caso es que la situación que tengo es distinta a la del hilo: no recibo ningún mensaje de error al descomprimir, puedo sacar archivos únicos del archivador y restaurarlos... el problema que tengo es que los archivos restaurados pierden su formato y pasan a ser ficheros ascii, es decir, invervibles :-( Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió: 0pasan a ser ficheros invervibles :-(
Saludos,
Pues sí que te quedan raros... invervibles :P. Prueba lo que te dice rafa. ¿Has probado a abrirlos en windows? -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 13:35 +0200, César Alonso escribió:
Camaleón escribió: 0pasan a ser ficheros invervibles :-(
Pues sí que te quedan raros... invervibles :P. Prueba lo que te dice rafa.
¡Grrr! :-)
¿Has probado a abrirlos en windows?
Buena idea. Voy a bajar el 7-zip portable a ver qué me cuenta. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 13:54 +0200, Camaleón escribió:
El 2009-09-02 a las 13:35 +0200, César Alonso escribió:
Camaleón escribió: 0pasan a ser ficheros invervibles :-(
Pues sí que te quedan raros... invervibles :P. Prueba lo que te dice rafa.
¡Grrr! :-)
¿Has probado a abrirlos en windows?
Buena idea. Voy a bajar el 7-zip portable a ver qué me cuenta.
Al final he bajado el "PeaZip". Qué programita tan majo :-) Y con este programa bajo windows, también lo he podido restaurar sin problemas. Gracias :-D Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-09-02 a las 13:54 +0200, Camaleón escribió:
El 2009-09-02 a las 13:35 +0200, César Alonso escribió:
Camaleón escribió: 0pasan a ser ficheros invervibles :-( Pues sí que te quedan raros... invervibles :P. Prueba lo que te dice rafa. ¡Grrr! :-)
¿Has probado a abrirlos en windows? Buena idea. Voy a bajar el 7-zip portable a ver qué me cuenta.
Al final he bajado el "PeaZip". Qué programita tan majo :-)
Y con este programa bajo windows, también lo he podido restaurar sin problemas.
Gracias :-D
Saludos,
Tiene que ser algo relacionado con los "filesystems" No sé, cualquier parche, he notado, que puede afectar el comportamiento de estas herramientas. Personalmente no me gustan nada los comprimidos de cosas importantes. -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Tuesday 01 September 2009 20:46:06 Camaleón wrote:
Hola,
Estoy intentando rescatar de un archivador que tengo (creado con tar) un documento de la copia de seguridad, pero al restaurarlo el archivo está corrupto. De hecho, todos los archivos que tengo dentro del tar.gz se restauran mal.
Como Ark se queda colgado al explorar el archivador (supongo que debido al tamaño de > 3 GB. de tar.gz) lo estoy haciendo con MC que es lento, pero funciona (quiero decir que me permite navegar y extraer los archivos que quiero restaurar).
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
Estoy con openSUSE 10.3 y el formato de la partición de backup es ext3.
¿Con qué versión de tar hiciste el archivo? ¿Otro Unix? ¿Otro tar (BSD tar en vez de GNU tar)? No debería afectar, pero los diferentes tars tienen diferentes comportamientos por defecto que tienes que anular/activar con opciones, por ejemplo: --old-archive o --format=posix. Si haces un: tar tzvf archivo.tgz ¿Qué dice? Prueba lo que te dicen del uudecode. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 11:40 +0200, Rafa Grimán escribió:
On Tuesday 01 September 2009 20:46:06 Camaleón wrote:
(...)
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
Estoy con openSUSE 10.3 y el formato de la partición de backup es ext3.
¿Con qué versión de tar hiciste el archivo?
*** tar (GNU tar) 1.17 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. ***
¿Otro Unix?
Sí, mi equipo habitual, openSUSE 10.3.
¿Otro tar (BSD tar en vez de GNU tar)? No debería afectar, pero los diferentes tars tienen diferentes comportamientos por defecto que tienes que anular/activar con opciones, por ejemplo: --old-archive o --format=posix.
No, es el tar que va en suse 10.3. El archivador lo creo con: tar -cvjf /home/hpc02/backup/hpc02/20090523.tar.gz /home/hpc02/Desktop/files --exclude=folder [...]
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice: *** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores *** Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-? Un "file" sobre el archivador me dice: *** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Prueba lo que te dicen del uudecode.
Sí, ya lo he probado, pero me da error. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/9/2 Camaleón
El archivador lo creo con:
tar -cvjf /home/hpc02/backup/hpc02/20090523.tar.gz /home/hpc02/Desktop/files --exclude=folder [...]
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Entonces es un tar.bz ;-) Si ejecutas "tar tjvf archivo" que te dice? -- Kind Regards -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/9/2 Gabriel
Entonces es un tar.bz ;-)
Si ejecutas "tar tjvf archivo" que te dice?
Encontré esto, puede que funcione: http://ubuntuforums.org/archive/index.php/t-1117636.html -- Kind Regards -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 09:00 -0300, Gabriel escribió:
2009/9/2 Camaleón:
El archivador lo creo con:
tar -cvjf /home/hpc02/backup/hpc02/20090523.tar.gz /home/hpc02/Desktop/files --exclude=folder [...]
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Entonces es un tar.bz ;-)
Sí, me di cuenta ayer, al ejecutar el comando que me dijiste. Le pasé el "file" y ya me dijo lo que era "realmente" O:-)
Si ejecutas "tar tjvf archivo" que te dice?
Pues empieza a listar los directorios y archivos... :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 02 September 2009 14:08:22 Camaleón wrote:
El 2009-09-02 a las 09:00 -0300, Gabriel escribió:
2009/9/2 Camaleón:
El archivador lo creo con:
tar -cvjf /home/hpc02/backup/hpc02/20090523.tar.gz /home/hpc02/Desktop/files --exclude=folder [...]
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Entonces es un tar.bz ;-)
Sí, me di cuenta ayer, al ejecutar el comando que me dijiste. Le pasé el "file" y ya me dijo lo que era "realmente" O:-)
Si ejecutas "tar tjvf archivo" que te dice?
Pues empieza a listar los directorios y archivos... :-?
Bien, eso es que el archivo en sí no está corrupto. Pero eso de usar la misma ruta (origen y destino) y hacer un tar recursivo ... ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 18:31 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 14:08:22 Camaleón wrote:
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Entonces es un tar.bz ;-)
Sí, me di cuenta ayer, al ejecutar el comando que me dijiste. Le pasé el "file" y ya me dijo lo que era "realmente" O:-)
Si ejecutas "tar tjvf archivo" que te dice?
Pues empieza a listar los directorios y archivos... :-?
Bien, eso es que el archivo en sí no está corrupto.
Al no recibir ningún mensaje de error, eso es lo que pensaba.
Pero eso de usar la misma ruta (origen y destino) y hacer un tar recursivo ... ;)
¿Mande? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 02 September 2009 17:42:05 Camaleón wrote:
El 2009-09-02 a las 18:31 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 14:08:22 Camaleón wrote:
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Entonces es un tar.bz ;-)
Sí, me di cuenta ayer, al ejecutar el comando que me dijiste. Le pasé el "file" y ya me dijo lo que era "realmente" O:-)
Si ejecutas "tar tjvf archivo" que te dice?
Pues empieza a listar los directorios y archivos... :-?
Bien, eso es que el archivo en sí no está corrupto.
Al no recibir ningún mensaje de error, eso es lo que pensaba.
Pero eso de usar la misma ruta (origen y destino) y hacer un tar recursivo ... ;)
¿Mande? :-?
Si haces un: tar cvf /home/hpc02/backup/archivo.tar /home/hpc02 ^^^^^^^^^^^ ^^^^^^^^^^^ destino origen Luego destino y origen son lo mismo. Estás haciendo un tar recursivo ... a menos que se me haya escapado algo 0;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 18:11 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 17:42:05 Camaleón wrote:
Pero eso de usar la misma ruta (origen y destino) y hacer un tar recursivo ... ;)
¿Mande? :-?
Si haces un:
tar cvf /home/hpc02/backup/archivo.tar /home/hpc02 ^^^^^^^^^^^ ^^^^^^^^^^^ destino origen
Luego destino y origen son lo mismo. Estás haciendo un tar recursivo ... a menos que se me haya escapado algo 0;)
¿Eso es malo/peligroso? :-? No había caído... Tengo el disco montado en la home de mi usuario, pero lo excluyo expresamente al hacer la copia... ¿Es mejor montar el disco en otro lado para evitar "bucles barbudos"? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 02 September 2009 18:40:30 Camaleón wrote:
El 2009-09-02 a las 18:11 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 17:42:05 Camaleón wrote:
Pero eso de usar la misma ruta (origen y destino) y hacer un tar recursivo ... ;)
¿Mande? :-?
Si haces un:
tar cvf /home/hpc02/backup/archivo.tar /home/hpc02 ^^^^^^^^^^^ ^^^^^^^^^^^ destino origen
Luego destino y origen son lo mismo. Estás haciendo un tar recursivo ... a menos que se me haya escapado algo 0;)
¿Eso es malo/peligroso? :-? No había caído...
Para mi sí porque soy muy despistado.
Tengo el disco montado en la home de mi usuario, pero lo excluyo expresamente al hacer la copia...
OK, entonces no debería haber bucles.
¿Es mejor montar el disco en otro lado para evitar "bucles barbudos"?
Depende. Yo lo separo todo para evitar problemas, descuidos, olvidos, ... Pero eso es porque soy muy despistado/olvidadizo. Aquellos que son más meticulosos, cuidadosos, atentos, ... no lo necesitan ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-03 a las 11:21 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 18:40:30 Camaleón wrote:
¿Es mejor montar el disco en otro lado para evitar "bucles barbudos"?
Depende. Yo lo separo todo para evitar problemas, descuidos, olvidos, ... Pero eso es porque soy muy despistado/olvidadizo. Aquellos que son más meticulosos, cuidadosos, atentos, ... no lo necesitan ;)
No, no es mala idea. De hecho en los servidores los volúmenes los monté en la raíz para evitar problemas. Quizá deba seguir el mismo sistema en mi equipo :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-03 a las 10:43 +0200, Camaleón escribió:
No, no es mala idea.
De hecho en los servidores los volúmenes los monté en la raíz para evitar problemas. Quizá deba seguir el mismo sistema en mi equipo :-)
Se termina teniendo un montón de cosas en el raiz. Creo que es mejor tener un directorio como /data o /vols para meterlos juntos, y facilita el listar los directorios "estandar" separados de los "extra". - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqgJRcACgkQtTMYHG2NR9UNigCcD+pdx3iBXe9AedzBHeGgGFgF M94An0exTzv4FW0SkiwUlhR4j3OgpLzw =3Sww -----END PGP SIGNATURE-----
Rafa Griman escribió:
Hola :)
On Wednesday 02 September 2009 14:08:22 Camaleón wrote:
El 2009-09-02 a las 09:00 -0300, Gabriel escribió:
2009/9/2 Camaleón:
El archivador lo creo con:
tar -cvjf /home/hpc02/backup/hpc02/20090523.tar.gz /home/hpc02/Desktop/files --exclude=folder [...]
Si haces un:
tar tzvf archivo.tgz
¿Qué dice? Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k *** Entonces es un tar.bz ;-) Sí, me di cuenta ayer, al ejecutar el comando que me dijiste. Le pasé el "file" y ya me dijo lo que era "realmente" O:-)
Si ejecutas "tar tjvf archivo" que te dice? Pues empieza a listar los directorios y archivos... :-?
Bien, eso es que el archivo en sí no está corrupto. Pero eso de usar la misma ruta (origen y destino) y hacer un tar recursivo ... ;)
Rafa
No creo que sea cuestión de eso. A mí me han dado problemas comprimidos bien sencillitos. Lo bueno, es que hasta la fecha, casi siempre los he podido arreglar en windows... También es verdad que cuando me obligaban a usar windows, estos entuertos los "desfacía" en linux con total naturalidad. -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 02 September 2009 13:40:40 Camaleón wrote:
El 2009-09-02 a las 11:40 +0200, Rafa Grimán escribió:
On Tuesday 01 September 2009 20:46:06 Camaleón wrote:
(...)
¿Alguna idea de por qué se restauran mal los datos? ¿Hay alguna limitación en el tamaño que debe tener el archivador? Recuerdo que estuvimos hablando del formato ZIP que sí tenía ese límite ¿pero el gzip también lo tiene o el problema es otro?
Estoy con openSUSE 10.3 y el formato de la partición de backup es ext3.
¿Con qué versión de tar hiciste el archivo?
*** tar (GNU tar) 1.17 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason. ***
¿Otro Unix?
Sí, mi equipo habitual, openSUSE 10.3.
¿Otro tar (BSD tar en vez de GNU tar)? No debería afectar, pero los diferentes tars tienen diferentes comportamientos por defecto que tienes que anular/activar con opciones, por ejemplo: --old-archive o --format=posix.
No, es el tar que va en suse 10.3.
Vamos que el tar con el que creaste el archivo y el tar con el que pretendes extraer del archivo son el mismo.
El archivador lo creo con:
tar -cvjf /home/hpc02/backup/hpc02/20090523.tar.gz /home/hpc02/Desktop/files --exclude=folder [...]
Un par de cosas: 1.- tar -cvjf ... y le pones de nombre .gz ... qué mala eres !!! Eso lo haces para engañar a los que te quieren robar los datos ;) 2.- vamos a ver, estás haciendo un tar recursivo !!!!! Origen y destino son el mismo, o están en el mismo sitio: /home/hpc02 Normal que se te corrompan los ficheros. Deberías hacer un: tar -cvjf /OTRA/RUTA/backup/hpc02/20090523.tar.gz /home/hpc02/...
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
Prueba: tar tjvf 20090829.tar.bz2
Prueba lo que te dicen del uudecode.
Sí, ya lo he probado, pero me da error.
Saludos,
HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-02 a las 13:40 +0200, Camaleón escribió:
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqeyswACgkQtTMYHG2NR9WuaACdHS/j+3cTZXqKgPwoY7MwOwwh LUsAn0UV21KUnf8VpxESce3hwoUJIeCs =/wFP -----END PGP SIGNATURE-----
El 2009-09-02 a las 21:43 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 13:40 +0200, Camaleón escribió:
Si haces un:
tar tzvf archivo.tgz
¿Qué dice?
Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc.
¡Y un cuerno de ñu! >:-) Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII. De hecho, fue lo primero que probé ayer por la noche, pensando que al darle una extensión "tar.gz" siendo un "tar.bz2" podía haber sido el origen del problema. Pero no fue así, afortundamamente. Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-( Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-? También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-09-02 a las 21:43 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 13:40 +0200, Camaleón escribió:
Si haces un:
tar tzvf archivo.tgz
¿Qué dice? Dice:
*** gzip: stdin: not in gzip format tar: Child returned status 1 tar: Salida con error demorada desde errores anteriores ***
Ah, sí, porque la compresión utilizada en bz2 no gzip ¿eso influye en algo en todo este lío? :-?
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k *** ¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc.
¡Y un cuerno de ñu! >:-)
Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII.
De hecho, fue lo primero que probé ayer por la noche, pensando que al darle una extensión "tar.gz" siendo un "tar.bz2" podía haber sido el origen del problema. Pero no fue así, afortundamamente.
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Saludos,
No lo uses... es rarito, y siempre lo fue. -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-02 a las 23:14 +0200, César Alonso escribió:
Camaleón escribió:
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k *** ¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc.
¡Y un cuerno de ñu! >:-)
Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII.
(...)
No lo uses... es rarito, y siempre lo fue.
Admito sugerencias para sustituirlo ;-) Pero a día de hoy el MC es mi herramienta de trabajo. Sin él iría de cabeza con los servidores donde no tengo ningún DE instalado. Que me guste trabajar en línea de comandos no significa que me desenvuelva medianamente bien con ella O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-09-02 a las 23:14 +0200, César Alonso escribió:
Camaleón escribió:
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k *** ¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc. ¡Y un cuerno de ñu! >:-)
Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII.
(...)
No lo uses... es rarito, y siempre lo fue.
Admito sugerencias para sustituirlo ;-)
Pero a día de hoy el MC es mi herramienta de trabajo. Sin él iría de cabeza con los servidores donde no tengo ningún DE instalado. Que me guste trabajar en línea de comandos no significa que me desenvuelva medianamente bien con ella O:-)
Saludos,
Pues en el Software Store de linuxmint he visto algo parecido... Lo miro y si lo encuentro te digo. -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 03/09/09, csalinux escribió:
Camaleón escribió:
Admito sugerencias para sustituirlo ;-)
Pero a día de hoy el MC es mi herramienta de trabajo. Sin él iría de cabeza con los servidores donde no tengo ningún DE instalado. Que me guste trabajar en línea de comandos no significa que me desenvuelva medianamente bien con ella O:-)
Pues en el Software Store de linuxmint he visto algo parecido... Lo miro y si lo encuentro te digo.
Me pasa lo mismo que a este usuario del comentario (akanashiro) :-P http://linuxmint.com/software/?sec=item&id=1144&release=5 Por cierto, la idea de poner comenarios (como tienen estos del linux-mentolado) pero en el webpin no estaría de más, así la gente podría valorar las aplicaciones del OBS, indicar algún problema o si les son útiles, etc... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-09-02 a las 23:14 +0200, César Alonso escribió:
Camaleón escribió:
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k *** ¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc. ¡Y un cuerno de ñu! >:-)
Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII.
(...)
No lo uses... es rarito, y siempre lo fue.
Admito sugerencias para sustituirlo ;-)
Pero a día de hoy el MC es mi herramienta de trabajo. Sin él iría de cabeza con los servidores donde no tengo ningún DE instalado. Que me guste trabajar en línea de comandos no significa que me desenvuelva medianamente bien con ella O:-)
Saludos,
Mira aquí, alguno hay. http://www.libervis.com/wiki/index.php?title=Table_of_Equivalent_Software -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 03/09/09, csalinux escribió:
Mira aquí, alguno hay.
http://www.libervis.com/wiki/index.php?title=Table_of_Equivalent_Software
Algunos enlaces no van... y los que sí funcionan enlazan a programas que parece que tienen una funcionalidad muy básica ¿no? No conozco ninguno :-? He visto otro en la wikipedia: http://en.wikipedia.org/wiki/Dired Pero también parece un poco antiguo... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-02 a las 23:04 +0200, Camaleón escribió:
El 2009-09-02 a las 21:43 +0200, Carlos E. R. escribió:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc.
¡Y un cuerno de ñu! >:-)
Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII.
Ah, güeno :-)
De hecho, fue lo primero que probé ayer por la noche, pensando que al darle una extensión "tar.gz" siendo un "tar.bz2" podía haber sido el origen del problema. Pero no fue así, afortundamamente.
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Bueno, yo ya te he dicho que eso es un problema del propio formato, que no prevee una manera de saber a priori que compresión se ha usado, y certificar que lo que ha regenerado es correcto. El zip contiene un CRC en el archivo que permite verificar que se ha reconstruido correctamente cada fichero original... por algo es más robusto.
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
El mc no es lo más adecuado para extraer unos pocos ficheros de un tar grande, porque lo que hace es expandirlo entero primero. Y, por lo visto, no adivina el formato correcto para expandir el archivo.
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Puedes ponerle espacio temporal en el anfitrión via nfs. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqe+XEACgkQtTMYHG2NR9VzFQCfZ0OhjdnldZcQT4dkk6yIM05I uTQAoIcVhcGMyQXYJEww0e6y3KO9ILLq =SKe6 -----END PGP SIGNATURE-----
El 2009-09-03 a las 01:02 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 23:04 +0200, Camaleón escribió:
El 2009-09-02 a las 21:43 +0200, Carlos E. R. escribió:
(...)
De hecho, fue lo primero que probé ayer por la noche, pensando que al darle una extensión "tar.gz" siendo un "tar.bz2" podía haber sido el origen del problema. Pero no fue así, afortundamamente.
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Bueno, yo ya te he dicho que eso es un problema del propio formato, que no prevee una manera de saber a priori que compresión se ha usado, y certificar que lo que ha regenerado es correcto. El zip contiene un CRC en el archivo que permite verificar que se ha reconstruido correctamente cada fichero original... por algo es más robusto.
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
El mc no es lo más adecuado para extraer unos pocos ficheros de un tar grande, porque lo que hace es expandirlo entero primero. Y, por lo visto, no adivina el formato correcto para expandir el archivo.
Extraje el tar y navegué por el tar. Falló de igual forma :-(
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Thursday 03 September 2009 08:26:30 Camaleón wrote:
El 2009-09-03 a las 01:02 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 23:04 +0200, Camaleón escribió:
El 2009-09-02 a las 21:43 +0200, Carlos E. R. escribió:
(...)
De hecho, fue lo primero que probé ayer por la noche, pensando que al darle una extensión "tar.gz" siendo un "tar.bz2" podía haber sido el origen del problema. Pero no fue así, afortundamamente.
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Bueno, yo ya te he dicho que eso es un problema del propio formato, que no prevee una manera de saber a priori que compresión se ha usado, y certificar que lo que ha regenerado es correcto. El zip contiene un CRC en el archivo que permite verificar que se ha reconstruido correctamente cada fichero original... por algo es más robusto.
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
cpio te crea archivos tar y luego para comprimir puedes usar lo qu emás te guste. Yo antes usaba gzip, pero ahora me he pasado a lzma. Si no me equivoco, lzma está soportado en muuuuuchso sistemas :)
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
El mc no es lo más adecuado para extraer unos pocos ficheros de un tar grande, porque lo que hace es expandirlo entero primero. Y, por lo visto, no adivina el formato correcto para expandir el archivo.
Extraje el tar y navegué por el tar. Falló de igual forma :-(
Revisa si puedes configurar el comportamiento de MC con archivos. Ponía el ejemplo en el correo anterior con FTP y formato de ficheros.
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir?
¿Qué VM usas? Si usas VirtualBox, tienes un icono que te permite compartir un directorio del anfitrión con la VM. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-03 a las 09:37 +0200, Rafa Grimán escribió:
On Thursday 03 September 2009 08:26:30 Camaleón wrote:
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
cpio te crea archivos tar y luego para comprimir puedes usar lo qu emás te guste. Yo antes usaba gzip, pero ahora me he pasado a lzma. Si no me equivoco, lzma está soportado en muuuuuchso sistemas :)
Lzma no viene de serie en opensuse 10.3 :-P
El mc no es lo más adecuado para extraer unos pocos ficheros de un tar grande, porque lo que hace es expandirlo entero primero. Y, por lo visto, no adivina el formato correcto para expandir el archivo.
Extraje el tar y navegué por el tar. Falló de igual forma :-(
Revisa si puedes configurar el comportamiento de MC con archivos. Ponía el ejemplo en el correo anterior con FTP y formato de ficheros.
Sí, voy a comprobar eso. Pero es algo que debería hacer solo, ya que si sabe que es un .tar debería ponerse en modo "auto" O:-).
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir?
¿Qué VM usas? Si usas VirtualBox, tienes un icono que te permite compartir un directorio del anfitrión con la VM.
Sí, es VB. ¿Pero crees que esa opción me serviría para este caso? Quizá necesite necesite espacio en /tmp para ejecutar la operación de extracción... Espera, lo que hice fue acceder vía sftp con nautilus al equipo donde estaba el archivador de 3 GB y lo abrí "al vuelo", no lo copié al disco. Así fue como me saltó el mensaje. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Thursday 03 September 2009 11:02:07 Camaleón wrote:
El 2009-09-03 a las 09:37 +0200, Rafa Grimán escribió:
On Thursday 03 September 2009 08:26:30 Camaleón wrote:
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
cpio te crea archivos tar y luego para comprimir puedes usar lo qu emás te guste. Yo antes usaba gzip, pero ahora me he pasado a lzma. Si no me equivoco, lzma está soportado en muuuuuchso sistemas :)
Lzma no viene de serie en opensuse 10.3 :-P
Vaya :( My bad.
El mc no es lo más adecuado para extraer unos pocos ficheros de un tar grande, porque lo que hace es expandirlo entero primero. Y, por lo visto, no adivina el formato correcto para expandir el archivo.
Extraje el tar y navegué por el tar. Falló de igual forma :-(
Revisa si puedes configurar el comportamiento de MC con archivos. Ponía el ejemplo en el correo anterior con FTP y formato de ficheros.
Sí, voy a comprobar eso. Pero es algo que debería hacer solo, ya que si sabe que es un .tar debería ponerse en modo "auto" O:-).
Eso es cierto ... ¡Hey! Nop, eso es coartar la lbertad del usuario, deberían aparecer checkboxes en blanco para que el usuario decida lo que quiere hacer o no hacer ;)
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir?
¿Qué VM usas? Si usas VirtualBox, tienes un icono que te permite compartir un directorio del anfitrión con la VM.
Sí, es VB.
¿Pero crees que esa opción me serviría para este caso?
Uffff ... ahí me pillas porque no he hecho ese tipo de experimentos 0:)
Quizá necesite necesite espacio en /tmp para ejecutar la operación de extracción... Espera, lo que hice fue acceder vía sftp con nautilus al equipo donde estaba el archivador de 3 GB y lo abrí "al vuelo", no lo copié al disco. Así fue como me saltó el mensaje.
Mucha mezcla. ¿No has oido que eso de mezclar es malo? Luego viene la resaca ;) A lo mejor se quedó sin buffers, sin espacio temporal, algún paquete se quedó por el camino tomando unos vinos con otro paquete, la CPU se cansó, ... Yo soy más de la opción de conectar remotamente al equipo pro SSH puro y duro y usar las herramientas básicas (tar, gzip, bzip2, find, ls, ...) y cunado ya tengo lo que quiero, me hago un tar y lo traigo vía scp o sftp, pero cuando ya he hecho todo. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-03 a las 11:27 +0200, Rafa Grimán escribió:
On Thursday 03 September 2009 11:02:07 Camaleón wrote:
cpio te crea archivos tar y luego para comprimir puedes usar lo qu emás te guste. Yo antes usaba gzip, pero ahora me he pasado a lzma. Si no me equivoco, lzma está soportado en muuuuuchso sistemas :)
Lzma no viene de serie en opensuse 10.3 :-P
Vaya :( My bad.
Ná, al opensuse 10.3 le quedan dos telediarios, pero ene ste momento es lo que tengo :-)
Revisa si puedes configurar el comportamiento de MC con archivos. Ponía el ejemplo en el correo anterior con FTP y formato de ficheros.
Sí, voy a comprobar eso. Pero es algo que debería hacer solo, ya que si sabe que es un .tar debería ponerse en modo "auto" O:-).
Eso es cierto ... ¡Hey! Nop, eso es coartar la lbertad del usuario, deberían aparecer checkboxes en blanco para que el usuario decida lo que quiere hacer o no hacer ;)
Es una cuestión puramente técnica... sí, ya sé que lo decías en broma ;-) La cuarta ley de la robótica debería ser "un sistema inteligente no debe cambiar el formato de los archivos sin que haya una razón técnica y lógica para hacerlo" :-P
¿Qué VM usas? Si usas VirtualBox, tienes un icono que te permite compartir un directorio del anfitrión con la VM.
Sí, es VB.
¿Pero crees que esa opción me serviría para este caso?
Uffff ... ahí me pillas porque no he hecho ese tipo de experimentos 0:)
Vale X-) ya haré más pruebas este fin de semana.
Quizá necesite necesite espacio en /tmp para ejecutar la operación de extracción... Espera, lo que hice fue acceder vía sftp con nautilus al equipo donde estaba el archivador de 3 GB y lo abrí "al vuelo", no lo copié al disco. Así fue como me saltó el mensaje.
Mucha mezcla. ¿No has oido que eso de mezclar es malo? Luego viene la resaca ;) A lo mejor se quedó sin buffers, sin espacio temporal, algún paquete se quedó por el camino tomando unos vinos con otro paquete, la CPU se cansó, ...
Yo soy más de la opción de conectar remotamente al equipo pro SSH puro y duro y usar las herramientas básicas (tar, gzip, bzip2, find, ls, ...) y cunado ya tengo lo que quiero, me hago un tar y lo traigo vía scp o sftp, pero cuando ya he hecho todo.
O.k. Lo primero que pensé fue "he hecho mal la copia" y lo segundo fue "el MC no podrá gestionarlo, la versión que tengo es antigua y tendrá algún problema, etc..." por eso me fui a la opensuse 11.1 que al llevar gnome, el programa archivador es distinto del ark, y el MC será más modernico. Mi intención era descartar que la copia se hubiera generado mal o que estuviera corrupta. Al poder abrirlo desde windows con el PeaZip ya me volvió a circular la sangre :-} Probaré como dices, copiando primero a la VM y abriendo con MC después :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-03 a las 09:37 +0200, Rafa Griman escribió:
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
cpio te crea archivos tar y luego para comprimir puedes usar lo qu emás te guste. Yo antes usaba gzip, pero ahora me he pasado a lzma. Si no me equivoco, lzma está soportado en muuuuuchso sistemas :)
Cualquier sistema de archivado que comprima el conjunto a posteriori es crearse problemas. Debe ser un sistema que archive y comprima de manera integrada, con checksums o CRC de cada fichero original, y que no se equivoque nunca al descomprimir usando un formato incorrecto. Asímismo, si hay un error de grabación o transmisión en una zona del archivador, debe afectar unicamente a un fichero (o dos contiguos), nunca al conjunto. Estas características las cumple el zip... pero no el tar.gz ni el cpio.gz (o lzma). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqfzPcACgkQtTMYHG2NR9XIDwCcCO8WNLkT7IZsMRKCeuYpN4wx tAQAn3dzyoP11GDqRhmSakwGIgABWVg9 =LbZa -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-03 a las 08:26 +0200, Camaleón escribió:
El 2009-09-03 a las 01:02 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 23:04 +0200, Camaleón escribió:
Bueno, yo ya te he dicho que eso es un problema del propio formato, que no prevee una manera de saber a priori que compresión se ha usado, y certificar que lo que ha regenerado es correcto. El zip contiene un CRC en el archivo que permite verificar que se ha reconstruido correctamente cada fichero original... por algo es más robusto.
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
El zip lo cumple todo, salvo una cosa crucial: archivadores grandes, es decir, el límite de los 4 gigas. Tiene que ser xip64, que como has dicho, no tiene soporte universal. No sé que recomendar. El tar comprimido no es bueno, pero es lo que hay :-( O fraccionar en varios archivadores de menor tamaño en zip, si es fatible.
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
El mc no es lo más adecuado para extraer unos pocos ficheros de un tar grande, porque lo que hace es expandirlo entero primero. Y, por lo visto, no adivina el formato correcto para expandir el archivo.
Extraje el tar y navegué por el tar. Falló de igual forma :-(
Porque expandiría con gzip :-?
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir?
Claro que lo sabes, es que no te has dado cuenta :-) En el anfitrión exportas un directorio cualquiera (via nfs), y en el huesped lo importas, montándolo en /tmp, durante el arranque. Logicamente hay que tener cuidado con los permisos, en tmp cualquiera debe poder escribir. Mira, yo hago una cosa muy rara: en un huesped 11.1 monto particiones reiserfs encriptadas en un disco externo via usb. Luego las exporto via nfs, y después las importo en el anfitrión, 11.0. ¿porqué? Pues porque el 11.0 tiene un bug al manejar particiones reiserfs via usb, las corrompe de mala manera. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqfytYACgkQtTMYHG2NR9Ur3QCeOqcwRU4i6Q/xAFgjRcYdnaZ9 fbwAmwU2hmh+zJerG15glzstcIcDqYg9 =qgbd -----END PGP SIGNATURE-----
El 2009-09-03 a las 15:55 +0200, Carlos E. R. escribió:
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir?
Claro que lo sabes, es que no te has dado cuenta :-)
:-)
En el anfitrión exportas un directorio cualquiera (via nfs), y en el huesped lo importas, montándolo en /tmp, durante el arranque. Logicamente hay que tener cuidado con los permisos, en tmp cualquiera debe poder escribir.
Hum... ayer hice un pequeño experimento. Tengo openSUSE 11.1 como invitado en virtualbox y el host en windows xp, así que siguiendo la idea de Rafa, compartí un directorio desde el xp y lo monté la openSUSE 11.1 virtualizada. Después, siguiendo la idea que dices de montar el espacio en /tmp, pues así lo hice, a lo bruto (renombré /tmp a /tmp_orig, creé un directorio /tmp donde monté el recurso compartido del windows y le puse los mismos permisos a ese directorio). La mezcla era un poco rara, pero funcionó. Desde el MC de openSUSE 11.1 accedí al tar.gz de 3 y pico gigas y extraje el archivo. El resultado fue el mismo: lo convierte a formato ascii. Ya que tenía el archivador accesible y el espacio montado en /tmp, también probé a abrir el archivador con la aplicación de gnome "file roller" y éste sí lo extrajo sin problemas, perfecto. Lo cual sigue dejando al MC en una posición nada favorable pero sigo sin saber por qué lo convierte a ascii >:-?
Mira, yo hago una cosa muy rara: en un huesped 11.1 monto particiones reiserfs encriptadas en un disco externo via usb. Luego las exporto via nfs, y después las importo en el anfitrión, 11.0.
Yeech :-P
¿porqué? Pues porque el 11.0 tiene un bug al manejar particiones reiserfs via usb, las corrompe de mala manera.
Cosas veredes... pero si tienes problemas con la 11.0 y el reiserfs + usb, ¿por qué no usas ext3, xfs o cualquier otros sistema de archivos? ¿O también están afectados? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-04 a las 11:36 +0200, Camaleón escribió:
La mezcla era un poco rara, pero funcionó. Desde el MC de openSUSE 11.1 accedí al tar.gz de 3 y pico gigas y extraje el archivo. El resultado fue el mismo: lo convierte a formato ascii.
Ya que tenía el archivador accesible y el espacio montado en /tmp, también probé a abrir el archivador con la aplicación de gnome "file roller" y éste sí lo extrajo sin problemas, perfecto.
Lo cual sigue dejando al MC en una posición nada favorable pero sigo sin saber por qué lo convierte a ascii >:-?
Bueno, creo que he encontrado el patrón de fallo. No se trata del tamaño del archivador (he estado generando varios archivos con dd de 1 GB y ejecutando la misma rutina de tar para hacer la copia de seguridad y el MC lo recupera sin problemas, en su formato original sin transformarlo a ascii). El MC empieza a fallar (a tener poblemas con la recuperación de los archivos) cuando hago una copia del directorio de ~/.kde. Si excluyo este directorio, no hay ningún problema. ¿Qué hay ahí que le pueda dar guerra? Pues sólo se me ocurre: a) Nombres de archivo (formato maildir del tipo "1204652569.10828.1TLZL:2,S") b) Rutas largas De hecho, cuando intento restaurar un correo, el MC saca un mensaje de error (ahora sí) y dice "imposible leer el archivo de origen (...) error de entrada/salida (5)". Si aborto la operación, me dice "el archivo está incompleto ¿desea conservarlo?, le digo "mantener" y el archivo restaurado ocupa 0 bytes, es decir, que no lo restaura. Si alguien lo quiere (com)probar, los ingredientes con: - Kmail con formato de correos maildir (o equivalente) - Orden para crear el archivador: tar -cvjf /destino/copia/archivador.tar.bz2 /home/usuario/.kde/share/apps/kmail/mail/ Ojo, que dependiendo de la cantidad de correos puede ocupar bastante y el proceso es lento. Se puede sleccionar un directorio de correo determinado para que sea más rápido. - Una vez terminado, ejecutar MC y acceder a /destino/copia/archivador.tar.bz2. Navegar hasta cualquier de los mensajes, seleccionar uno e intentar copiarlo al escritorio, por ejemplo, con F5. ¿Conclusión? Pues que la copia se realiza bien, que el archivador no está corrupto y que el MC (o la rutina que usa para navegar por el archivador comprimido mediante "utar") tiene problemas con el formato (o más bien con el nombre de los archivos) maildir, no lo maneja bien. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-04 a las 21:04 +0200, Camaleón escribió:
Bueno, creo que he encontrado el patrón de fallo.
Debe tener problemas con ciertos nombres con caracteres "extraños", por lo que cuentas. Bugzilla >:-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqiJJEACgkQtTMYHG2NR9U9PwCeNxLuJprtzCdk2WOmdHgFIqaV UN4AnAzEecXBQQAdP7XMsPs/ej+zFbd9 =shU3 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-04 a las 11:36 +0200, Camaleón escribió:
El 2009-09-03 a las 15:55 +0200, Carlos E. R. escribió:
Puedes ponerle espacio temporal en el anfitrión via nfs.
Eso no sé cómo se hace :-?. ¿Tienes algún enlace o referencia que pueda seguir?
Claro que lo sabes, es que no te has dado cuenta :-)
:-)
En el anfitrión exportas un directorio cualquiera (via nfs), y en el huesped lo importas, montándolo en /tmp, durante el arranque. Logicamente hay que tener cuidado con los permisos, en tmp cualquiera debe poder escribir.
Hum... ayer hice un pequeño experimento.
Tengo openSUSE 11.1 como invitado en virtualbox y el host en windows xp, así que siguiendo la idea de Rafa, compartí un directorio desde el xp y lo monté la openSUSE 11.1 virtualizada.
Ah, del xp... Es una curiosa "feature" del vb, eso de compartir directorios.
Después, siguiendo la idea que dices de montar el espacio en /tmp, pues así lo hice, a lo bruto (renombré /tmp a /tmp_orig, creé un directorio /tmp donde monté el recurso compartido del windows y le puse los mismos permisos a ese directorio).
Lo puedes montar sin renombrar el antiguo, no pasa nada. El contenido del /tmp original desaparece aparentemente, es decir, queda inaccesible, pero al desmontar vuelve a aparecer.
La mezcla era un poco rara, pero funcionó. Desde el MC de openSUSE 11.1 accedí al tar.gz de 3 y pico gigas y extraje el archivo. El resultado fue el mismo: lo convierte a formato ascii.
Aummm...
Ya que tenía el archivador accesible y el espacio montado en /tmp, también probé a abrir el archivador con la aplicación de gnome "file roller" y éste sí lo extrajo sin problemas, perfecto.
Lo cual sigue dejando al MC en una posición nada favorable pero sigo sin saber por qué lo convierte a ascii >:-?
Ya he visto que lo has averiguado después.
Mira, yo hago una cosa muy rara: en un huesped 11.1 monto particiones reiserfs encriptadas en un disco externo via usb. Luego las exporto via nfs, y después las importo en el anfitrión, 11.0.
Yeech :-P
X'-) Es más una prueba de concepto que otra cosa. Me funciona, pero es lento.
¿porqué? Pues porque el 11.0 tiene un bug al manejar particiones reiserfs via usb, las corrompe de mala manera.
Cosas veredes... pero si tienes problemas con la 11.0 y el reiserfs + usb, ¿por qué no usas ext3, xfs o cualquier otros sistema de archivos? ¿O también están afectados? :-?
Pues porque están llenos de datos y es un disco creado bajo 10.3, que lo usaba sin problemas. Las xfs encriptadas tienen un bug peor, dejan frito al sistema. Y las particiones ext3 sobre usb tienen otro problema, propio de toda ext3: son lentas de narices en la verificación, y con transporte USB te puedes imaginar que se vuelven unas narices quevedianas ("sayón o escriba"). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqhsMoACgkQtTMYHG2NR9WwnACeL4rWYpsiwEHk9LhLGBhxkcco /v4AniHyC2voXerVboY5FYTxOX41Sqde =4aI8 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-03 a las 08:26 +0200, Camaleón escribió:
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
El zip lo cumple todo, salvo una cosa crucial: archivadores grandes, es decir, el límite de los 4 gigas. Tiene que ser xip64, que como has dicho, no tiene soporte universal.
No sé que recomendar. El tar comprimido no es bueno, pero es lo que hay :-(
O fraccionar en varios archivadores de menor tamaño en zip, si es fatible.
He visto en la lista inglesa que sugieren pax. No lo conozco. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqpXGwACgkQtTMYHG2NR9V9twCeOmjytBmlZpnABe+UX5R662XP P98AnRH1Pqkl+CHkq6aP7RfJx/2hx4Ds =gcla -----END PGP SIGNATURE-----
El 2009-09-10 a las 22:07 +0200, Carlos E. R. escribió:
El 2009-09-03 a las 15:55 +0200, Carlos E. R. escribió:
El 2009-09-03 a las 08:26 +0200, Camaleón escribió:
Soy toda oídos. Pero necesito una solución para archivadores grandes y que utilice un formato normalizado, que sea más seguro que el tar.bz2 y que sea manipulable / accesible en el 98% de los sistemas.
El zip lo cumple todo, salvo una cosa crucial: archivadores grandes, es decir, el límite de los 4 gigas. Tiene que ser xip64, que como has dicho, no tiene soporte universal.
No sé que recomendar. El tar comprimido no es bueno, pero es lo que hay :-(
O fraccionar en varios archivadores de menor tamaño en zip, si es fatible.
He visto en la lista inglesa que sugieren pax. No lo conozco.
Sí, he estado siguiendo el hilo para ver qué opina la gente. No hay un ganador claro: unos abogan por tar con compresión, otros por cpio, otros por rsync y este del pax. También he oído por ahí algo del "afio". El "pax" lo tengo instalado en la 10.3 pero no sé qué ventajas tendría con respecto al tar comprimido ni cómo se podría gestionar el archivador resultante desde entornos windows :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-14 a las 13:48 +0200, Camaleón escribió:
He visto en la lista inglesa que sugieren pax. No lo conozco.
Sí, he estado siguiendo el hilo para ver qué opina la gente.
No hay un ganador claro: unos abogan por tar con compresión, otros por cpio, otros por rsync y este del pax. También he oído por ahí algo del "afio".
¿afio? No se si me suena.
El "pax" lo tengo instalado en la 10.3 pero no sé qué ventajas tendría con respecto al tar comprimido ni cómo se podría gestionar el archivador resultante desde entornos windows :-?
Ni idea. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqumwYACgkQtTMYHG2NR9UHRQCcCQqcMkJ5H0VNTDLuzkoSeh7d RkEAnju9wLtojGgwadon6o18uHgwBL5Z =zXgp -----END PGP SIGNATURE-----
Te olvidaste de lo que aparece en el pie de cada mensaje:
Para dar de baja la suscripción, mande un mensaje a:
opensuse-es+unsubscribe@opensuse.org
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@opensuse.org
2009/9/15
unsubscibe
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 02 September 2009 23:04:32 Camaleón wrote:
El 2009-09-02 a las 21:43 +0200, Carlos E. R. escribió:
El 2009-09-02 a las 13:40 +0200, Camaleón escribió:
[...]
Un "file" sobre el archivador me dice:
*** 20090829.tar.bz2: bzip2 compressed data, block size = 900k ***
¡Ah! bzip2. Claro, la extensión es incorrecta y confunde al mc.
¡Y un cuerno de ñu! >:-)
Algo serio le para al MC pero no sé qué es. Por Internet no he encontrado nada relacionado con ese problema y si genero un archivador (de menor tamaño) de la misma forma que lo hice con el de 3GB. el MC lo gestiona correctamente y descomprime los datos sin transformarlos a ASCII.
De hecho, fue lo primero que probé ayer por la noche, pensando que al darle una extensión "tar.gz" siendo un "tar.bz2" podía haber sido el origen del problema. Pero no fue así, afortundamamente.
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
Puede ser que el MC haga algo similar a un tar a STDOUT y luego un cat. Es decir, como si hicieras un cat del fichero, de ahí que parezca ASCII. Es decir, el MC tiene mal configurado (en openSUSE o por norma general) cómo tratar un archivo (archivo != fichero). No me refiero al MIME, me refiero a la hora de trabajar con archivos, cómo extraer los ficheros que hay en el archivo. Por si no me he explicado bien, es como los clientes FTP, que le tienes (tenías) que poner si vas (ibas) a trabajar en modo binario o ASCII, si te equivocas, el fichero que te descargas es ASCII en vez de jpg, por ejemplo. Esto hace que sea inservible y tengas que reiniciar la descarga cambiando el modo de tratar los ficheros.
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Por cierto, si quieres formato tar con algo más de seguridad o fiabilidad, tienes cpio. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-03 a las 09:31 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 23:04:32 Camaleón wrote:
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
Puede ser que el MC haga algo similar a un tar a STDOUT y luego un cat. Es decir, como si hicieras un cat del fichero, de ahí que parezca ASCII. Es decir, el MC tiene mal configurado (en openSUSE o por norma general) cómo tratar un archivo (archivo != fichero). No me refiero al MIME, me refiero a la hora de trabajar con archivos, cómo extraer los ficheros que hay en el archivo.
archive -> archivador file -> archivo O:-) Vale, pero entonces el MC fallaría en todos los achivadores creados, no en unos sí y en otros no. No veo un patrón de fallo en este caso, ya que los archivadores de tamaño reducido los gestiona sin problemas.
Por si no me he explicado bien, es como los clientes FTP, que le tienes (tenías) que poner si vas (ibas) a trabajar en modo binario o ASCII, si te equivocas, el fichero que te descargas es ASCII en vez de jpg, por ejemplo. Esto hace que sea inservible y tengas que reiniciar la descarga cambiando el modo de tratar los ficheros.
Voy a buscar información sobre eso.
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Por cierto, si quieres formato tar con algo más de seguridad o fiabilidad, tienes cpio.
¿tar + bz2 + cpio? ¿Cpio no es similar al tar o se pueden combinar? :-? Aquí hay un artículo interesante, me lo guardo para más tarde :-) Choosing a format for data backups – tar vs cpio http://www.g-loaded.eu/2007/12/01/choosing-a-format-for-data-backups-tar-vs-... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Thursday 03 September 2009 10:52:02 Camaleón wrote:
El 2009-09-03 a las 09:31 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 23:04:32 Camaleón wrote:
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
Puede ser que el MC haga algo similar a un tar a STDOUT y luego un cat. Es decir, como si hicieras un cat del fichero, de ahí que parezca ASCII. Es decir, el MC tiene mal configurado (en openSUSE o por norma general) cómo tratar un archivo (archivo != fichero). No me refiero al MIME, me refiero a la hora de trabajar con archivos, cómo extraer los ficheros que hay en el archivo.
archive -> archivador file -> archivo
O:-)
Esta discusión ya se tuvo hace tiempo en la lista ya que a la hora de traducir hay gente que piensa que archive = file cuando conceptualmente no lo son. Un archivo es un contenedor lógico de ficheros o, lo que es lo mismo, un fichero que contiene ficheros. El problema surge cuando en Unix todo son ficheros, curiosamente nadie confunde un fichero ordinario en Unix con un directorio o un archivo con un directorio o un directorio con un fichero que representa un dispositivo de bloques ;) Es como lo de las enzimas: todas las enzimas son proteínas, pero no todas las proteínas son enzimas. Pues los archivos igual: todos los archivos son ficheros, pero no todos los ficheros son archivos.
Vale, pero entonces el MC fallaría en todos los achivadores creados, no en unos sí y en otros no. No veo un patrón de fallo en este caso, ya que los archivadores de tamaño reducido los gestiona sin problemas.
OK, eso es algo que no sabía (no uso el MC 0:) Hmmm ... mira que hacerme pensar a estas horas ;) La verdad es que no se me ocurre nada salvo el tamaño del fichero ... Ah, puede ser que se quede sin buffer. Ejemplo, si haces un: find / -iname "*" | less el sistema no mostrará todo porque el buffer se queda sin espacio, por lo que necesitas hacer un: find / -iname "*" | xargs less ¿Puede ser eso? Carlos (Robinson) ha dicho que MC te abre el archivo entero y luego saca el fichero en cuestión. Si hablamos de un archivo de 3 GB (bueno, realmente casi cualquier cosa mayor al buffer que tiene), el buffer contiene una pequeña parte por lo que a lo mejor el MC corrompe "sin querer" el fichero a extraer. O bien, lo trata como ASCII porque trabajar con un BIN consume muchos recursos.
Por si no me he explicado bien, es como los clientes FTP, que le tienes (tenías) que poner si vas (ibas) a trabajar en modo binario o ASCII, si te equivocas, el fichero que te descargas es ASCII en vez de jpg, por ejemplo. Esto hace que sea inservible y tengas que reiniciar la descarga cambiando el modo de tratar los ficheros.
Voy a buscar información sobre eso.
En los clientes actuales, se trabaja por defecto con BIN (por lo menos los que conozco yo tanto GUI como CLI en Linux). Hay un cliente FTP en MS-Windows cuyo nombre no puedo recordar ... (a ver si me va a decir algo la SGAE por plagiar un libro ;) que te muestra radio buttons* con ASCII, BIN y no me acuerdo qué otra opción. Por defecto viene marcado el BIN (si no recuerdo mal). * espero que no empecemos una nueva discusión sobre si deberían ser radio buttons, check boxes, estar o no activadas por defecto, libertad de decisión, ... ;)
También intenté abrir el archivador desde la openSUSE 11.1 que tengo en la VM, pero a mitad camino de abrirlo me ha saltado diciendo que "no tenía espacio en disco" (claro, porque la VM sólo tiene un disco de 8GB, tamaño fijo :-P) así que me he quedado con las ganas de ver cómo gestionaba el archivador un sistema más modernico.
Por cierto, si quieres formato tar con algo más de seguridad o fiabilidad, tienes cpio.
¿tar + bz2 + cpio? ¿Cpio no es similar al tar o se pueden combinar? :-?
cpio a secas con bzip2 (u otro (des)compresor). cpio lo desarrollaron como una mejora a tar por lo que comenta Carlos (Robinson) que tar no comprueba la integridad de los datos.
Aquí hay un artículo interesante, me lo guardo para más tarde :-)
Choosing a format for data backups – tar vs cpio http://www.g-loaded.eu/2007/12/01/choosing-a-format-for-data-backups-tar-vs -cpio/
Interesante :) Gracias !!! Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-09-03 a las 11:17 +0200, Rafa Grimán escribió:
On Thursday 03 September 2009 10:52:02 Camaleón wrote:
El 2009-09-03 a las 09:31 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 23:04:32 Camaleón wrote:
Además, no puede fallar de la forma en la que lo hace, restaurando con un formato erróneo un archivo y sin decir ni pío :-(
Algo le hace "saltar" y transformar en ascii el archivo restaurado, pero no sé qué puede ser :-?
Puede ser que el MC haga algo similar a un tar a STDOUT y luego un cat. Es decir, como si hicieras un cat del fichero, de ahí que parezca ASCII. Es decir, el MC tiene mal configurado (en openSUSE o por norma general) cómo tratar un archivo (archivo != fichero). No me refiero al MIME, me refiero a la hora de trabajar con archivos, cómo extraer los ficheros que hay en el archivo.
archive -> archivador file -> archivo
O:-)
Esta discusión ya se tuvo hace tiempo en la lista ya que a la hora de traducir hay gente que piensa que archive = file cuando conceptualmente no lo son. Un archivo es un contenedor lógico de ficheros o, lo que es lo mismo, un fichero que contiene ficheros. El problema surge cuando en Unix todo son ficheros, curiosamente nadie confunde un fichero ordinario en Unix con un directorio o un archivo con un directorio o un directorio con un fichero que representa un dispositivo de bloques ;)
Es como lo de las enzimas: todas las enzimas son proteínas, pero no todas las proteínas son enzimas. Pues los archivos igual: todos los archivos son ficheros, pero no todos los ficheros son archivos.
El concepto lo tenemos claro, lo que discutíamos era el término. Un archive puede ser un archivo (un archivo de archivos) :-) Un archive puede ser un fichero (un fichero de ficheros) :-) En español no queda claro si se refiere a un "contenedor de" por eso lo dejamos como "archivador" que aporta esa idea de agrupación, de conjunto, que no tiene "archivo".
Vale, pero entonces el MC fallaría en todos los achivadores creados, no en unos sí y en otros no. No veo un patrón de fallo en este caso, ya que los archivadores de tamaño reducido los gestiona sin problemas.
OK, eso es algo que no sabía (no uso el MC 0:) Hmmm ... mira que hacerme pensar a estas horas ;)
La verdad es que no se me ocurre nada salvo el tamaño del fichero ... Ah, puede ser que se quede sin buffer. Ejemplo, si haces un:
find / -iname "*" | less
el sistema no mostrará todo porque el buffer se queda sin espacio, por lo que necesitas hacer un:
find / -iname "*" | xargs less
¿Puede ser eso? Carlos (Robinson) ha dicho que MC te abre el archivo entero y luego saca el fichero en cuestión. Si hablamos de un archivo de 3 GB (bueno, realmente casi cualquier cosa mayor al buffer que tiene), el buffer contiene una pequeña parte por lo que a lo mejor el MC corrompe "sin querer" el fichero a extraer. O bien, lo trata como ASCII porque trabajar con un BIN consume muchos recursos.
No sé... pero si falla (o si tiene alguna limitación) al menos yo la desconocía, por eso lo pregunté :-? Pero oye, que el equipo que uso tiene 4 GB de ram (3 visibles por el sistema) y 4 cores ¿necesito más potencia? O:-)
Por si no me he explicado bien, es como los clientes FTP, que le tienes (tenías) que poner si vas (ibas) a trabajar en modo binario o ASCII, si te equivocas, el fichero que te descargas es ASCII en vez de jpg, por ejemplo. Esto hace que sea inservible y tengas que reiniciar la descarga cambiando el modo de tratar los ficheros.
Voy a buscar información sobre eso.
En los clientes actuales, se trabaja por defecto con BIN (por lo menos los que conozco yo tanto GUI como CLI en Linux). Hay un cliente FTP en MS-Windows cuyo nombre no puedo recordar ... (a ver si me va a decir algo la SGAE por plagiar un libro ;) que te muestra radio buttons* con ASCII, BIN y no me acuerdo qué otra opción. Por defecto viene marcado el BIN (si no recuerdo mal).
Es que no le veo sentido. Cambiar de ascii a bin así, sin más, sin avisar, sin preguntar... no me parece lo más correcto.
* espero que no empecemos una nueva discusión sobre si deberían ser radio buttons, check boxes, estar o no activadas por defecto, libertad de decisión, ... ;)
Sí, sí, sí... :-P
Por cierto, si quieres formato tar con algo más de seguridad o fiabilidad, tienes cpio.
¿tar + bz2 + cpio? ¿Cpio no es similar al tar o se pueden combinar? :-?
cpio a secas con bzip2 (u otro (des)compresor). cpio lo desarrollaron como una mejora a tar por lo que comenta Carlos (Robinson) que tar no comprueba la integridad de los datos.
Aquí hay un artículo interesante, me lo guardo para más tarde :-)
Choosing a format for data backups – tar vs cpio http://www.g-loaded.eu/2007/12/01/choosing-a-format-for-data-backups-tar-vs -cpio/
Interesante :) Gracias !!!
Aún no lo he leído completo, pero al final el autor dice que se queda con tar >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Thursday 03 September 2009 12:06:33 Camaleón wrote:
El 2009-09-03 a las 11:17 +0200, Rafa Grimán escribió:
On Thursday 03 September 2009 10:52:02 Camaleón wrote:
El 2009-09-03 a las 09:31 +0200, Rafa Grimán escribió:
On Wednesday 02 September 2009 23:04:32 Camaleón wrote:
[...]
Vale, pero entonces el MC fallaría en todos los achivadores creados, no en unos sí y en otros no. No veo un patrón de fallo en este caso, ya que los archivadores de tamaño reducido los gestiona sin problemas.
OK, eso es algo que no sabía (no uso el MC 0:) Hmmm ... mira que hacerme pensar a estas horas ;)
La verdad es que no se me ocurre nada salvo el tamaño del fichero ... Ah, puede ser que se quede sin buffer. Ejemplo, si haces un:
find / -iname "*" | less
el sistema no mostrará todo porque el buffer se queda sin espacio, por lo que necesitas hacer un:
find / -iname "*" | xargs less
¿Puede ser eso? Carlos (Robinson) ha dicho que MC te abre el archivo entero y luego saca el fichero en cuestión. Si hablamos de un archivo de 3 GB (bueno, realmente casi cualquier cosa mayor al buffer que tiene), el buffer contiene una pequeña parte por lo que a lo mejor el MC corrompe "sin querer" el fichero a extraer. O bien, lo trata como ASCII porque trabajar con un BIN consume muchos recursos.
No sé... pero si falla (o si tiene alguna limitación) al menos yo la desconocía, por eso lo pregunté :-?
Ahí ya no te puedo ayudar, no lo uso 0:)
Pero oye, que el equipo que uso tiene 4 GB de ram (3 visibles por el sistema) y 4 cores ¿necesito más potencia? O:-)
Sería más cosa del buffer, no de la RAM total. ¿4 GB de RAM? ¿Sólo? Ah, que es un teléfono móvil ;) [...]
* espero que no empecemos una nueva discusión sobre si deberían ser radio buttons, check boxes, estar o no activadas por defecto, libertad de decisión, ... ;)
Sí, sí, sí... :-P
Porfiplis !!!! Aunque yo creo que deberíamos preguntar primero si queremos una discusión sobre estos temas. Podríamos lanzar una votación en openFATE para saber si la gente (lectores de las listas de correo) quieren un thread nuevo sobre esto. Obviamente la votación será con foto, DNI/cédula, muestra de orina, huella dactilar y árbol genealógico. Sin olvidarnos de un acta notarial, permiso de un juez y juramento sobre el hardware y sistema operativo utilizado. ;)
Por cierto, si quieres formato tar con algo más de seguridad o fiabilidad, tienes cpio.
¿tar + bz2 + cpio? ¿Cpio no es similar al tar o se pueden combinar? :-?
cpio a secas con bzip2 (u otro (des)compresor). cpio lo desarrollaron como una mejora a tar por lo que comenta Carlos (Robinson) que tar no comprueba la integridad de los datos.
Aquí hay un artículo interesante, me lo guardo para más tarde :-)
Choosing a format for data backups – tar vs cpio http://www.g-loaded.eu/2007/12/01/choosing-a-format-for-data-backups-ta r-vs -cpio/
Interesante :) Gracias !!!
Aún no lo he leído completo, pero al final el autor dice que se queda con tar >:-)
Da que pensar ... Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-03 a las 11:17 +0200, Rafa Griman escribió:
archive -> archivador file -> archivo
O:-)
Esta discusión ya se tuvo hace tiempo en la lista ya que a la hora de traducir hay gente que piensa que archive = file cuando conceptualmente no lo son. Un archivo es un contenedor lógico de ficheros o, lo que es lo mismo, un fichero que contiene ficheros. El problema surge cuando en Unix todo son ficheros, curiosamente nadie confunde un fichero ordinario en Unix con un directorio o un archivo con un directorio o un directorio con un fichero que representa un dispositivo de bloques ;)
Es como lo de las enzimas: todas las enzimas son proteínas, pero no todas las proteínas son enzimas. Pues los archivos igual: todos los archivos son ficheros, pero no todos los ficheros son archivos.
Está claro que archive =/= file, pero por desgracia, en español se acepta que archivo = fichero, está así en los diccionarios. Por tanto, decidimos traducir file por archivo o fichero, y archive por archivador. Personalmente prefiero file por fichero y archive por archivo, pero el acuerdo es distinto :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqfz28ACgkQtTMYHG2NR9WsXwCgj7/u9eah5uz4tRhhXXrGymCk mAgAnRyMikfoW2eaxoTuL0y6RZXV0giJ =QbBK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-03 a las 10:52 +0200, Camaleón escribió:
Aquí hay un artículo interesante, me lo guardo para más tarde :-)
Choosing a format for data backups – tar vs cpio http://www.g-loaded.eu/2007/12/01/choosing-a-format-for-data-backups-tar-vs-...
Ojo: no usan compresión durante la prueba, y eso afecta muchísimo. No vale esa comparación. El cpio se considera más robusto, pero no lo es si el resultado lo comprimes. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqfzjwACgkQtTMYHG2NR9WgbQCeKOQVjXSyfBdDgYoPj/mGHlQC oa8AniADmWPXsbIONegDCWolbsHXH7jD =LvqH -----END PGP SIGNATURE-----
participants (9)
-
Camaleón -
Carlos E. R. -
cheperobert -
csalinux -
francisco f -
Gabriel -
Juan Erbes -
marc＠kura.de -
Rafa Griman