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