opensuse
[Arriba] [Todas las Listas]

Re: [DIAGNOSTICADO] Re: [opensuse] Howto reparación - corrupt jpeg arch

To: opensuse@xxxxxxxxxxxx
Subject: Re: [DIAGNOSTICADO] Re: [opensuse] Howto reparación - corrupt jpeg archivo - cualquier cosa nuevo allí?
From: "Brian K. White" <brian@xxxxxxxxx>
Date: Mon, 19 Sep 2011 15:56:15 -0400
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Sep 2011 15:57:27 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <4E778EEE.5070600@suddenlinkmail.com>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
Organization: Aljex Software Inc.
References: <4E4C4914.2050209@suddenlinkmail.com> <4E77858B.7000307@suddenlinkmail.com> <4E7786E8.7090708@dodin.org> <4E778EEE.5070600@suddenlinkmail.com>
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
En 9/19/2011 2:50 PM, David *C. *Rankin Escribió:
En 09/19/2011 01:16 PM, *jdd escribió:
*Le 19/09/2011 20:10, David *C. *Rankin Un *écrit :

error, pero todavía tiene interior de basura. Algo como una cruz-archivo
enlazado en la tarjeta que causa la basura en los archivos. Dejarlo al DOS
*filesystem en la tarjeta a cosas de desorden arriba :)

cuándo escribes (o leído) un *flash tarjeta, una parte grande de la operación
es *buffered

yo en algún momento (también a menudo) aviso que uno puede *umount el lector *antes de*
toda
la lectura que/escribe las operaciones son completamente hecho. Mirada en el *blinking
*diode si
tienes un, mantiene *blinking

así que uno tiene que esperar* (30*s, #un minutos) antes de *unplugging

hace pocas semanas copié *VirtualBox imágenes de mi ordenador para copiarles
a un
ordenador 16 *km fuera

cuándo yo *tryed para copiar, los archivos donde presente pero *unreadable. Este
especial *usb
la llave  no ha dirigido :-(

suplico que el programa de copia primero crea los archivos, entonces, copia el dato

*jdd


Aquí, el dato fue escrito a la tarjeta de SD por el cámara, entonces la tarjeta
de SD fue puesta a un lector de tarjeta "de la memoria" en mi *laptop. Los archivos eran
entonces copiado de la tarjeta al paseo duro que utiliza un guión que
básicamente hizo:

*PICFILES=$(encuentra /*media/disco -tipo *f -*iname '*.*jpg')
*cp -*ur $*PICFILES /*img/Foto


trabajó bien. Entonces empecé experimentar los asuntos de corrupción.

No veo cómo la operación de copia de línea de orden podría tener no esperado
para el *buffer para escribir a disco antes de copiar la imagen próxima de la
tarjeta de SD??

Incluso después de la operación de copia fue acabada, yo  entonces *rsync los archivos
a un local *server antes de sacar la tarjeta de SD del lector. Esto
habría dejado al menos 1-5 minutos antes de traslado de tarjeta. Habría esperado un *rsync error si intentaba transferir un archivo que
todavía tuvo algún tipo de *buffer abierto?? (Podría ser mal allí.. Justo
no sé)

Cualquiera ve cómo el *multi-copia de archivos de la tarjeta de SD *via el guión
*snippets encima podría haber inducido la corrupción? A mí, (al menos tan de ahora)
el *culprit todavía parece un mal *filesystem en la tarjeta de SD. La tarjeta
era *reformatted dentro de poco después de este asunto de corrupción, pero dado
la corrupción, justo volví a un *digikam descarga directo del
cámara bastante que una copia de la tarjeta de SD él. No he tenido un
problema desde entonces. Quizás otra prueba es en orden.

Pensamientos? *Guidance?

Si tú *unmounted antes de que sacaste, entonces eres bien. Si tú no *unmount, entonces ninguna cantidad de esperar es realmente *garanteed, a pesar de que normalmente *dbflush tendrá *flushed todo #cada 30 segundos.

Pero ningún hay ningún cronometrando problemas relacionados o fija. Si es montado, el *kernel mangos todos fluyen control (*serialization/bloqueando/esperando), y cuándo tú *unmount, cuándo el *umount regresos de orden entonces *umount y el *kernel ha prometido todo el mundo que son todo hecho y el *sd tarjeta él ha reconocido el último escribir tan completado, y el *sd la tarjeta no tiene un *ram *buffer *cache en él que perderá dato cuándo tú *unplug la tarjeta.

Aquella basura "de muestra" mirada *tantalizingly la imagen relacionó. *SVGFEConvolveMatrix *googles Arriba de cuando una función de manipulación de la imagen, el cual tan lejos cuando puedo decir, *shouldn;*t existe de hecho dentro de una imagen, pero ciertamente existe en software de manipulación de la imagen.

Te tiene probado corriendo una recuperación de imagen *util que escanea un paseo crudo o imagen de paseo y recupera archivos por reconocer *headers y otras estructuras de dato de imagen sabidas en el dato crudo, no, o al menos no exclusivamente, por mirar en el *filesystem. Recuperan varias clases de archivos pero no pretende para saber sus nombres. Acabas arriba con un ramo de archivos numerados. Les tienes que abrir para decidir lo que son y rebautizar o *discard les.

El punto sería esta clase de *util no dejaría el *filesystem *metadat decirlo dónde inicio de archivos y parón. Leería cada *byte del disco o imagen de disco de *zero para acabar, intentando reconocer *jpg y otras estructuras de dato y él producción 1.*jpg, 2.*png, *etc... Basado sólo encima es propio *parsing del dato crudo, no por consultar el GORDO *etc.

Hice esto para recuperar muchas imágenes eliminadas de mi *girlfriends *iphone después de él chocado y el único fija era a fábrica *reset, el cual implicó un formato. Yo la fábrica *reset para conseguir el teléfono vivo otra vez entonces inmediatamente *jailbroke lo y capturado un *dd imagen sobre la red y era capaz de recuperar millares de imágenes y otros archivos comunes del 8*G imagen. La mayoría era *junk naturalmente, navegador *cache e imágenes y clips de sonido que eran partes de *apps, pero también era muchos de las imágenes de cámara. Naturalmente algún material fue perdido para bueno desde el OS nuevo instala y el *jailbreaking proceso *overwrite algunos del paseo justo para conseguir al punto donde era incluso posible de conseguir un *dd imagen.

Naturalmente no recuerdo el nombre de aquel *app. No es en esta máquina. Pienso que era un apoyo-solo *app, no requiriendo instala, y es probablemente en casa en un paseo externo junto con el *dd imagen y los archivos recuperados.

--
*bkw
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


On 9/19/2011 2:50 PM, David C. Rankin wrote:
On 09/19/2011 01:16 PM, jdd wrote:
Le 19/09/2011 20:10, David C. Rankin a écrit :

error, but still have garbage inside. Something like a cross-linked
file on the card causing the garbage in the files. Leave it to the DOS
filesystem on the card to mess things up :)

when you write (or read) a flash card, a large part of the operation
is buffered

I sometime (too often) notice that one can umount the reader *before*
all the
reading/writing operations are completely done. Look at the blinking
diode if
you have one, it keep blinking

so one have to *wait* (30s, one minutes) before unplugging

few weeks ago I copied VirtualBox images from my computer to copy them
to a
computer 16 km away

when I tryed to copy, the files where present but unreadable. This
special usb
key do not have led :-(

I beg that the copy program first create the files, then, copy the data

jdd


Here, the data was written to the SD card by the camera, then the SD
card was put into a memory card "reader" on my laptop. The files were
then copied from the card to the hard drive using a script that
basically did:

PICFILES=$(find /media/disk -type f -iname '*.jpg')
cp -ur $PICFILES ~/img/photo


It worked well. Then I began experiencing the corruption issues.

I don't see how the command line copy operation could have not waited
for the buffer to write to disk before copying the next image from the
SD card??

Even after the copy operation was finished, I would then rsync the files
to a local server before removing the SD card from the reader. This
would have allowed at least 1-5 minutes before card removal. I would
have expected an rsync error if it was trying to transfer a file that
still had some type of buffer open?? (I could be wrong there.. I just
don't know)

Anybody see how the multi-copy of files from the SD card via the script
snippets above could have induced the corruption? To me, (at least as of
now) the culprit still looks like a bad filesystem on the SD card. The
card was reformatted shortly after this corruption issue, but given the
corruption, I just went back to a digikam download direct from the
camera rather than a copy from the SD card itself. I haven't had a
problem since. Perhaps another test is in order.

Thoughts? Guidance?

If you unmounted before you removed, then you're fine. If you didn't unmount, then no amount of waiting is really garanteed, although usually dbflush will have flushed everything every 30 seconds.

But no there are no timing related problems or fixes. If it's mounted, the kernel handles all flow control (serialization/blocking/waiting), and when you unmount, when the umount command returns then umount and the kernel have promised everyone that they are all done and the sd card itself has acknowledged the last write as completed, and the sd card does not have a ram buffer cache in it that will lose data when you unplug the card.

That sample "garbage" looked tantalizingly image related. SVGFEConvolveMatrix googles up as an image manipulation function, which as far as I can tell, shouldn;t exist actually inside an image, but certainly exists in image manipulation software.

Have you tried running an image recovery util that scans a raw drive or drive image and recovers files by recognizing headers and other known image data structures in the raw data, not, or at least not exclusively, by looking at the filesystem. They recover several kinds of files but don't pretend to know their names. You end up with a bunch of numbered files. You have to open them to decide what they are and rename or discard them.

The point would be this kind of util would not let the filesystem metadat tell it where files start and stop. It would read every byte of the disk or disk image from zero to end, trying to recognize jpg and other data structures and it would output 1.jpg, 2.png, etc... based only on it's own parsing of the raw data, not by consulting the FAT etc.

I did this to recover a lot of deleted images from my girlfriends iphone after it crashed and the only fix was to factory reset, which involved a format. I did the factory reset to get the phone alive again then immediately jailbroke it and captured a dd image over the network and was able to recover thousands of images and other common files from the 8G image. Most were junk of course, browser cache and images and sound clips that were parts of apps, but also were many of the camera images. Of course some stuff was lost for good since the new OS install and the jailbreaking process did overwrite some of the drive just to get to the point where it was even possible to get a dd image.

Of course I don't remember the name of that app. It's not on this machine. I think it was a stand-alone app, not requiring install, and it's probably at home on an external drive along with the dd image and the recovered files.

--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>