[opensuse-es] Problema con Disco Duro
Hola :-) A ver si alguien puede echarme una mano. Problema: Hace unos días hice una copia de un directorio (Fotografias) en un disco duro IDE (conectado al ordenador con un conector IDE-USB). Lo monté con la utilidad gráfica "Particionador", además si no recuerdo mal creo que lo formatee antes de copiar nada, y creo además que fue ext3. Hasta ahí todo bien. Moví los datos. Pues bien, resulta que cometí el error de mover los datos al disco (en lugar de copiar, y después de haber comprobado que la copia fuera restaurable, eliminar), con lo que evidentemente desapareció el directorio original y todo su contenido. Ahora resulta que no puedo recuperar el contenido del directorio. El sistema, cuando lo pincho por el USB, no me reconoce el disco. Si pongo en marcha el particionador, me lo reconoce, me dice que tiene un sistema de archivos Linux native, pero no puedo montarlo. Me dice: "Error. No está permitido asignar un punto de montaje a un dispositivo que no existe o con un sistema de archivos desconocido" Le paso el # /sbin/fsck /dev/sdd1 Y me muestra estos comentarios: fsck 1.40.2 (12-Jul-2007) e2fsk 1.40.2 (12-Jul-2007) No se puede encontrar el superbloque del ext2, está intentando reparar los bloques... fsck.ext2: Attempt to read block from filesystem resulted in short read mientras se revisaba el fichero de transacciones ext3 para /dev/sdd1 fsck.ext2 /dev/sdd1 failed (status 0x8). Run manually! Pues bien, ¿qué comando o comandos -con sus parámetros - debería pasar para arreglar el sistema de archivos e intentar recuperar los datos? Agradecido
??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-16 a las 15:36 +0100, JOSANable escribió:
Hola :-)
A ver si alguien puede echarme una mano.
Problema: Hace unos días hice una copia de un directorio (Fotografias) en un disco duro IDE (conectado al ordenador con un conector IDE-USB). Lo monté con la utilidad gráfica "Particionador", además si no recuerdo mal creo que lo formatee antes de copiar nada, y creo además que fue ext3. Hasta ahí todo bien. Moví los datos.
O sea, que era la primera vez que usabas ese disco.
Pues bien, resulta que cometí el error de mover los datos al disco (en lugar de copiar, y después de haber comprobado que la copia fuera restaurable, eliminar), con lo que evidentemente desapareció el directorio original y todo su contenido. Ahora resulta que no puedo recuperar el contenido del directorio. El sistema, cuando lo pincho por el USB, no me reconoce el disco. Si pongo en marcha el particionador, me lo reconoce, me dice que tiene un sistema de archivos Linux native, pero no puedo montarlo. Me dice: "Error. No está permitido asignar un punto de montaje a un dispositivo que no existe o con un sistema de archivos desconocido"
Le paso el # /sbin/fsck /dev/sdd1 Y me muestra estos comentarios: fsck 1.40.2 (12-Jul-2007) e2fsk 1.40.2 (12-Jul-2007) No se puede encontrar el superbloque del ext2, está intentando reparar los bloques... fsck.ext2: Attempt to read block from filesystem resulted in short read mientras se revisaba el fichero de transacciones ext3 para /dev/sdd1 fsck.ext2 /dev/sdd1 failed (status 0x8). Run manually!
A mi me suena a disco petado... o sea, chip usb petado, cables, historias...
Pues bien, ¿qué comando o comandos -con sus parámetros - debería pasar para arreglar el sistema de archivos e intentar recuperar los datos?
Mira que errores han salido en el log del kernel. O con dmesg. Y con "file -s /dev/sdd1", a ver que te suelta. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHZUDntTMYHG2NR9URAuVSAJsGF3hJlXgjf7f0pAWW/cDAVUnGDgCfRvwO tjx4R9F71buzvrDZkbOHqfc= =tk4V -----END PGP SIGNATURE-----
O sea, que era la primera vez que usabas ese disco.
No, ese disco lo he usado otras veces (incluso estuvo en su día pinchado en un IDE) De hecho antes tenía en él dos particiones, que usaba para copiar y guardar diversos datos (por ejemplo, para moverlos de algún ordenador a otro, o como copia de seguridad), y funcionaba.
A mi me suena a disco petado... o sea, chip usb petado, cables, historias...
No creo que sea ese el caso, con otro disco funciona perfectamente, y con ese mismo disco funcionaba todo correctamente hasta que sustituí las dos particiones por una sola partición e hice lo que indicaba en el correo anterior. Los conectores están bien. Yo me oriento a creer que el sistema de archivos no está como debería estar. Creo que debería pasar alguna herramienta para intentar recomponerlo. Pero no tengo claro qué opciones debo ponerle.
Mira que errores han salido en el log del kernel. O con dmesg.
Y con "file -s /dev/sdd1", a ver que te suelta.
# dmesg | /dev/sdd1 bash: /dev/sdd1: Permiso denegado # file -s /dev/sdd1 /dev/sdd1: data
- -- Saludos
Ídem. =��u��y��jV���+��"�f�u맙��j7������zϮ�˛���m�)z{.��+���j��zw�zZ�yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��
yo lo primero que haria seria sacarlo del usb, y enchufarlo en una cinta ide
interna, tratar de recuperar los datos y luego intentar nuevamente con el
usb.
de esa manera al menos eliminas la usb>ide, y con otros cables tambien, asi
eliminas los cables.
y solo te queda el problema del disco fisico y el sistema de archivos, pero
al menos ya tienes menos fuentes de posibles problemas
----- Original Message -----
From: "JOSANable"
O sea, que era la primera vez que usabas ese disco.
No, ese disco lo he usado otras veces (incluso estuvo en su día pinchado en un IDE) De hecho antes tenía en él dos particiones, que usaba para copiar y guardar diversos datos (por ejemplo, para moverlos de algún ordenador a otro, o como copia de seguridad), y funcionaba.
A mi me suena a disco petado... o sea, chip usb petado, cables, historias...
No creo que sea ese el caso, con otro disco funciona perfectamente, y con ese mismo disco funcionaba todo correctamente hasta que sustituí las dos particiones por una sola partición e hice lo que indicaba en el correo anterior. Los conectores están bien.
Yo me oriento a creer que el sistema de archivos no está como debería estar. Creo que debería pasar alguna herramienta para intentar recomponerlo. Pero no tengo claro qué opciones debo ponerle.
Mira que errores han salido en el log del kernel. O con dmesg.
Y con "file -s /dev/sdd1", a ver que te suelta.
# dmesg | /dev/sdd1 bash: /dev/sdd1: Permiso denegado
# file -s /dev/sdd1 /dev/sdd1: data
- -- Saludos
Ídem. =uyjV+"fu맙j7zϮ˛m)z{.+jzwzZyثy"wr&jw^yƣy)z{.^ˬz E-mail clasificado por el Idenfificador de Spam Inteligente. Para modificar la categora clasificada acceda a su webmail
Este mensaje ha sido verificado por el E-mail Protegido. Antivirus actualizado en 16/12/2007 / Versin: 0.91.2/5145
--------------------------------------------------------------------- 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 2007-12-16 a las 16:34 +0100, JOSANable escribió:
O sea, que era la primera vez que usabas ese disco.
No, ese disco lo he usado otras veces (incluso estuvo en su día pinchado en un IDE) De hecho antes tenía en él dos particiones, que usaba para copiar y guardar diversos datos (por ejemplo, para moverlos de algún ordenador a otro, o como copia de seguridad), y funcionaba.
Mmmm. Vale, pero primer uso después del formateo.
A mi me suena a disco petado... o sea, chip usb petado, cables, historias...
No creo que sea ese el caso, con otro disco funciona perfectamente, y con ese mismo disco funcionaba todo correctamente hasta que sustituí las dos particiones por una sola partición e hice lo que indicaba en el correo anterior. Los conectores están bien.
O estaban.
Yo me oriento a creer que el sistema de archivos no está como debería estar. Creo que debería pasar alguna herramienta para intentar recomponerlo. Pero no tengo claro qué opciones debo ponerle.
No estoy seguro.
Mira que errores han salido en el log del kernel. O con dmesg.
Y con "file -s /dev/sdd1", a ver que te suelta.
# dmesg | /dev/sdd1 bash: /dev/sdd1: Permiso denegado
¡Ostrás! Pues menos mal que te ha denegado el permiso, poco más, con un pequeño cambio en la orden, y te cargas la tabla de particiones y el inicio del disco. Hacer dmesg, dmesg a secas, sin nada más. Si no sabes lo que hace un comando lo miras en el manual, ¡leches! Se trata de ver los ultimos mensajes del kernel.
# file -s /dev/sdd1 /dev/sdd1: data
Pues macho... eso YA no es un disco de datos. Ahí no hay un sistema de ficheros. Un ext2 daría esto: nimrodel:~ # file -s /dev/hda6 /dev/hda6: Linux rev 1.0 ext2 filesystem data (mounted or unclean) Y esto un ext3: nimrodel:~ # file -s /dev/hdd6 /dev/hdd6: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files) Por probar otra cosa: "file -s /dev/sdd". Te debería salir algo como esto: nimrodel:~ # file -s /dev/hda /dev/hda: x86 boot sector; partition 2: ID=0xf, starthead 254, startsector 44885610, 580251735 sectors, code offset 0x48 nimrodel:~ # file -s /dev/hdb /dev/hdb: x86 boot sector; partition 2: ID=0x83, starthead 0, startsector 4192965, 48195 sectors; partition 3: ID=0xf, starthead 0, startsector 4241160, 73915065 sectors, code offset 0x48 nimrodel:~ # file -s /dev/hdd /dev/hdd: x86 boot sector; partition 2: ID=0x83, starthead 0, startsector 4192965, 64260 sectors; partition 3: ID=0x83, starthead 0, startsector 4257225, 64260 sectors; partition 4: ID=0xf, starthead 0, startsector 4321485, 308239155 sectors nimrodel:~ # Peeeero... también puede haber un sistema de ficheros. A ver si hay suerte. Para hacer probatinas, si tienes una partición con espacio libre suficiente para guardar un fichero del mismo tamaño que el disco ese entero, puedes hacer cosas como esta: dd if=/dev/hdd1 of=ficherogigante y luego se trata al 'ficherogigante' como si fuera el disco (fsck, mount, etc). Si el comando da un error al tratar de leer el disco, entonces el disco tiene problemas de lectura (se puede reintentar con dd_rescue). Si se puede leer entero, son problemas "logicos". - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHZXH1tTMYHG2NR9URAv8TAJ4igluH3xXtpo/4uotB08Cp/gk1CgCeL0yH Fk/Vudlhys2SufJVNqWQFAI= =4nGQ -----END PGP SIGNATURE-----
El 16/12/07, Carlos E. R. escribió:
dd if=/dev/hdd1 of=ficherogigante
Éste, este es el comando... me lo apunto O:-) ¿"ficherogigante" ocupa sólo el espacio del disco que contiene datos recuperables, no? Es decir, no todo el tamaño completo del disco :-?.
y luego se trata al 'ficherogigante' como si fuera el disco (fsck, mount, etc).
Y al montarlo, ¿mantiene el sistema de archivos de la partición original (ext2 / ext3 / reiserfs...) y su estructura de directorios o es una partición "en bruto" con una estructura distinta?
Si el comando da un error al tratar de leer el disco, entonces el disco tiene problemas de lectura (se puede reintentar con dd_rescue). Si se puede leer entero, son problemas "logicos".
El mensaje que le daba de "no se puede encontrar superbloque" (que por cierto, vaya traducción "chunga" para un mensaje tan importante :-P) es lo que me parece raro... ¿tan, vamos a decir "vulnerable", es ext3 como para perder la información básica de un volumen... por un mal apagado, por ejemplo? Si el disco ya tiene sus años... fale, pero si es un disco duro reciente, hum...Y luego dicen de reiserfs >:-) 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
Content-ID:
El 16/12/07, Carlos E. R. escribió:
dd if=/dev/hdd1 of=ficherogigante
Éste, este es el comando... me lo apunto O:-)
Lo he empleado varias veces. Es muy potente, y muy "bajo". Creo que hay ajustes que lo hacen más rápido si le dices el tamaño de bloque a usar y coincide con el que usa el dispositivo, pero... tal como está es más fácil de recordar.
¿"ficherogigante" ocupa sólo el espacio del disco que contiene datos recuperables, no? Es decir, no todo el tamaño completo del disco :-?.
Tal como lo puse, el mismo tamaño que la partición original, espacio en blanco y todo, sin comprimir, ni compactar, ni ordenar ni nada.
y luego se trata al 'ficherogigante' como si fuera el disco (fsck, mount, etc).
Y al montarlo, ¿mantiene el sistema de archivos de la partición original (ext2 / ext3 / reiserfs...) y su estructura de directorios o es una partición "en bruto" con una estructura distinta?
La esctructura original completa, tanto que puedes hacer: mount /ficherogigante /mnt/sitio y funciona. O hacer: fsck /ficherogigante y también funciona. Hay un tipo de ficheros, no recuerdo si reiser o xfs que combiene decirle que trabaja sobre un fichero y no un dispositivo. Espera... no estoy seguro si funcionan tal cual, o hay que meterle por medio un loop, con 'losetup' ... [mirando mis notas] ... vale, el fsck funciona tal cual, pero el mount se hace a través de un loop: mount -t ext3 -o loop=/dev/loop1 /ficherogigante /mnt/sitio ó losetup /dev/loop1 /ficherogigante file -s /dev/loop1 <==== comprobacion fsck /dev/loop1 mount /dev/loop1 /mnt/sitio ... losetup -a umount /dev/loop1 losetup -d /dev/loop1 ó Editas el fstab y creas una entrada apropiada: /ficherogigante /mnt/sitio ext3 loop,defaults 1 1 con lo que puedes montarlo y desmontarlo en una sóla operación sin especificar el loop exacto. Lo que no sé es como trabajar con una imagen entera incluyendo las particiones. Esto de arriba es una imagen de una partición.
Si el comando da un error al tratar de leer el disco, entonces el disco tiene problemas de lectura (se puede reintentar con dd_rescue). Si se puede leer entero, son problemas "logicos".
El mensaje que le daba de "no se puede encontrar superbloque" (que por
Me refiero al hacer el dd.
cierto, vaya traducción "chunga" para un mensaje tan importante :-P) es lo que me parece raro... ¿tan, vamos a decir "vulnerable", es ext3 como para perder la información básica de un volumen... por un mal apagado, por ejemplo?
No debería... pero cosas veredes. Yo he perdido, en un sólo fallo, una partición ext3 entera, sin posible recuperación, junto con una docena de particiones recuperables al completo, de varios tipos. En otra ocasión perdí una partición xfs entera, y finalmente (bueno, fué antes que las otras dos) una reiser por bug del reiser (corregido en su día). La xfs es irrecuperable por culpa de un bug en el recuperador de xfs, esto es, en 'xfs_repair', reportado (Bug 280905 ) y no corregido: de hecho, han pasado varios meses y nadie se ha molestado en pedirme datos.
Si el disco ya tiene sus años... fale, pero si es un disco duro reciente, hum...Y luego dicen de reiserfs >:-)
Pero oye, que Josanable usó ext3 - cree. Todos los sistemas con "journal" rápidos son vulnerables a fallos tipo hardware, como la desconexión repentina, guardan estructuras en memoria. Y el reiser aguanta un montón los apagones. En el ext3 se puede poner que el diario guarde no sólo los metadatos, sino también los datos: eso lo hace más resistente. Pero el xf es vulnerable. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHZbUVtTMYHG2NR9URAqsEAJ0VpPMMj4I249UuczfRNqICBOP4SACfTiCA lofBXyNvKBUd/14QqwFig8c= =sqwE -----END PGP SIGNATURE-----
Parece que la cosa se va arreglando, pero no sé todavía hasta dónde....
El comando que le he introducido es:
e2fsck -f -y -v /dev/sdd1
(Es un comando que usa la distro gparted-livecd)
Después he hecho lo del ficheroenorme, y ya veo algo (en binario).
(Seguiré investigando, cuando pueda)
El 17/12/07, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
El 2007-12-16 a las 20:38 +0100, Camaleón escribió:
El 16/12/07, Carlos E. R. escribió:
dd if=/dev/hdd1 of=ficherogigante
Éste, este es el comando... me lo apunto O:-)
Lo he empleado varias veces. Es muy potente, y muy "bajo". Creo que hay ajustes que lo hacen más rápido si le dices el tamaño de bloque a usar y coincide con el que usa el dispositivo, pero... tal como está es más fácil de recordar.
¿"ficherogigante" ocupa sólo el espacio del disco que contiene datos recuperables, no? Es decir, no todo el tamaño completo del disco :-?.
Tal como lo puse, el mismo tamaño que la partición original, espacio en blanco y todo, sin comprimir, ni compactar, ni ordenar ni nada.
y luego se trata al 'ficherogigante' como si fuera el disco (fsck, mount, etc).
Y al montarlo, ¿mantiene el sistema de archivos de la partición original (ext2 / ext3 / reiserfs...) y su estructura de directorios o es una partición "en bruto" con una estructura distinta?
La esctructura original completa, tanto que puedes hacer:
mount /ficherogigante /mnt/sitio
y funciona.
O hacer:
fsck /ficherogigante
y también funciona. Hay un tipo de ficheros, no recuerdo si reiser o xfs que combiene decirle que trabaja sobre un fichero y no un dispositivo.
Espera... no estoy seguro si funcionan tal cual, o hay que meterle por medio un loop, con 'losetup' ... [mirando mis notas] ... vale, el fsck funciona tal cual, pero el mount se hace a través de un loop:
mount -t ext3 -o loop=/dev/loop1 /ficherogigante /mnt/sitio
ó
losetup /dev/loop1 /ficherogigante file -s /dev/loop1 <==== comprobacion fsck /dev/loop1 mount /dev/loop1 /mnt/sitio ... losetup -a umount /dev/loop1 losetup -d /dev/loop1
ó
Editas el fstab y creas una entrada apropiada:
/ficherogigante /mnt/sitio ext3 loop,defaults 1 1
con lo que puedes montarlo y desmontarlo en una sóla operación sin especificar el loop exacto.
Lo que no sé es como trabajar con una imagen entera incluyendo las particiones. Esto de arriba es una imagen de una partición.
Si el comando da un error al tratar de leer el disco, entonces el disco tiene problemas de lectura (se puede reintentar con dd_rescue). Si se puede leer entero, son problemas "logicos".
El mensaje que le daba de "no se puede encontrar superbloque" (que por
Me refiero al hacer el dd.
cierto, vaya traducción "chunga" para un mensaje tan importante :-P) es lo que me parece raro... ¿tan, vamos a decir "vulnerable", es ext3 como para perder la información básica de un volumen... por un mal apagado, por ejemplo?
No debería... pero cosas veredes. Yo he perdido, en un sólo fallo, una partición ext3 entera, sin posible recuperación, junto con una docena de particiones recuperables al completo, de varios tipos. En otra ocasión perdí una partición xfs entera, y finalmente (bueno, fué antes que las otras dos) una reiser por bug del reiser (corregido en su día). La xfs es irrecuperable por culpa de un bug en el recuperador de xfs, esto es, en 'xfs_repair', reportado (Bug 280905 ) y no corregido: de hecho, han pasado varios meses y nadie se ha molestado en pedirme datos.
Si el disco ya tiene sus años... fale, pero si es un disco duro reciente, hum...Y luego dicen de reiserfs >:-)
Pero oye, que Josanable usó ext3 - cree.
Todos los sistemas con "journal" rápidos son vulnerables a fallos tipo hardware, como la desconexión repentina, guardan estructuras en memoria. Y el reiser aguanta un montón los apagones.
En el ext3 se puede poner que el diario guarde no sólo los metadatos, sino también los datos: eso lo hace más resistente.
Pero el xf es vulnerable.
- -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux)
iD8DBQFHZbUVtTMYHG2NR9URAqsEAJ0VpPMMj4I249UuczfRNqICBOP4SACfTiCA lofBXyNvKBUd/14QqwFig8c= =sqwE -----END PGP SIGNATURE-----
??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-19 a las 18:38 +0100, JOSANable escribió:
Parece que la cosa se va arreglando, pero no sé todavía hasta dónde....
El comando que le he introducido es:
e2fsck -f -y -v /dev/sdd1
(Es un comando que usa la distro gparted-livecd)
-f Force checking even if the file system seems clean. -y Assume an answer of `yes' to all questions; allows e2fsck to be used non-interactively. This option may not be specified at the same time as the -n or -p options. -v Verbose mode. Yo no hubiera usado "-y", no me atrevo. Yo hubiera usado "-p".
Después he hecho lo del ficheroenorme, y ya veo algo (en binario).
La cosa era hacerlo al revés: primero el ficherenorme, y luego el fsck sobre el fichero, no sobre la partición problemática. Se trata de hacer las pruebas con gaseosa. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHaXKXtTMYHG2NR9URAs8IAJ9QIkhAiFdwiubC/IN5EfGxgxn02QCeL4CN UzoFS6z7KJIXVndpqRoLOWE= =/jUX -----END PGP SIGNATURE-----
El 16/12/07, JOSANable escribió:
"Error. No está permitido asignar un punto de montaje a un dispositivo que no existe o con un sistema de archivos desconocido"
Intenta primero las pruebas menos traumáticas: - Montarlo desde consola (y revisar los mensajes del registro tras ejecutarlo) - Comprobar las entradas en el fstab por si hay alguna referencia incorrecta al disco - Si no hay ninguna entrada para el disco, prueba a añadirla de forma manual, para que al iniciar el equipo realice un chequeo e intente montarlo - Aunque sea un engorro, otra opción sería sacarlo de la caja usb y conectarlo a un puerto ide disponible. Si es un problema del usb, con ésto lo descartas
No se puede encontrar el superbloque del ext2, está intentando reparar los bloques... fsck.ext2: Attempt to read block from filesystem resulted in short read mientras se revisaba el fichero de transacciones ext3 para /dev/sdd1 fsck.ext2 /dev/sdd1 failed (status 0x8). Run manually!
Y si realmente se trata de lo que dice ese mensaje (superbloque
dañado), podrías intentar recuperarlo (yo nunca lo he hecho, y ésto
puede destruir datos, así que, mucho ojo).
En Google, aparece esta ayuda de un manual de suse (no sé la versión a
la que hace referencia):
http://www.l3jane.net/doc/linux/suse/suselinux-adminguide_es/ch11s05.html
***
11.5.2.2. Reparar sistemas de archivos
(...)
Ejemplo: cuando un sistema de archivos no puede montarse debido a un
superbloque no válido, lo más probable es que e2fsck tampoco pueda
arreglarlo. La solución consiste en utilizar las copias de seguridad
de superbloques que se encuentran cada 8192 bloques (bloque 8193,
16385…) en el sistema de archivos. Esto se puede hacer con el comando:
e2fsck -f -b 8193 /dev/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-16 a las 18:20 +0100, Camaleón escribió: ...
Lo que me extraña es que el disco realmente tenga algún problema lógico, si lo único que has hecho ha sido mover datos :-/
Podría, si se ha extraído mal. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHZXJ9tTMYHG2NR9URAt1tAJ0THzx5Dw3PqHctdaGpyvWTxo/N7QCfSDMA OZhFsVmK0uMtG9h9Fc+B3Mg= =ByJA -----END PGP SIGNATURE-----
participants (4)
-
Camaleón
-
Carlos E. R.
-
JOSANable
-
Juan Gustavo Fogelman