Mailinglist Archive: opensuse-es (821 mails)

[Rafa Griman <rafagriman@xxxxxxxxx>]

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@xxxxxxxxx
rgriman@xxxxxxxxxxxx

Happily using KDE 4.3.0 :)
--
Para dar de baja la suscripción, mande un mensaje a:
   opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
   opensuse-es+help@xxxxxxxxxxxx