Archivo dañado / perdido durante la transferencia? ¿Recuperación posible?

10

Estuve en la universidad hace unos días cuando intenté cortar y pegar un archivo de 500Mb (una grabación de video de 3gp) en mi disco H en una de las computadoras Linux de la red uni (Debian KDE 3.5).

No vi ningún mensaje de error que indicara que el trabajo de cortar y pegar había fallado, pero cuando miré el archivo pegado resultante, ahora aparece como un archivo de 60Mb (¡eso es una discrepancia de 440Mb!). ¡Mi archivo se encogió de alguna manera! ¿Se rompió el archivo en el proceso de pegarlo y este es el fragmento de un archivo copiado de forma incompleta?

Sospecho que lo que sucedió fue que la transferencia de archivos se interrumpió debido a las limitaciones de asignación de tamaño de la unidad H impuestas a los usuarios por los administradores.

Pero pensaría que Linux anticiparía que el archivo era más grande de lo que sería posible mover al destino deseado y abortaría la transferencia antes de que comenzara, no espere hasta que alcance un límite prohibido y luego cancele discretamente sin notificarme.

También en el caso de una transferencia de archivos interrumpida, ¿normalmente se espera que el archivo original permanezca intacto (es decir, no eliminado) en la unidad USB original?

El archivo aparece en el destino, pero ahora es mucho más pequeño y no funciona. El archivo original en la ubicación de origen en la unidad externa ha desaparecido, lo que sugiere que el trabajo se completó correctamente.

Este cambio de tamaño es bastante extraño y ahora parece que no tengo acceso al archivo original. Después de cortar y pegar, el original puede haberse eliminado de su ubicación de origen. La computadora ha manejado mal esta tarea, aparentemente haciéndome perder mi archivo, y me gustaría que me ayudaras a recuperar mi archivo.

Intenté recuperar el archivo en la tarjeta SD de mi teléfono usando PhotoRec y la herramienta forense Sleuthkit. Sin suerte. Las secciones eliminadas del disco pueden haber sido sobrescritas por nuevos datos. Entonces, progreso cero en el extremo de la fuente. ¿Alguna forma de recuperarse en el extremo de destino (es decir, mi red uni)?

peter@peter-deb:/media/E0FD-1813$ cd DCIM/
peter@peter-deb:/media/E0FD-1813/DCIM$ cd ..
peter@peter-deb:/media/E0FD-1813$ cd LOST.DIR/
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls -a
.  ..
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ 
ptrcao
fuente
¿Qué utilizó para copiar / mover el archivo? Además, ¿cómo esperaría que cualquier herramienta de copia sepa lo que los administradores del sistema establecen como tamaños de archivo máximos permitidos? Además, ¿estás seguro de que no hubo problemas con los dedos de tu lado? Ninguna herramienta de copia debería eliminar el archivo original si la copia no ha finalizado.
tshepang
La herramienta de copia era Konquerer o lo que fuera el administrador de archivos en esa computadora Debian de KDE 3.5. Estoy seguro de que no disloqué el conector USB en la duración del trabajo de transferencia si eso es lo que quieres decir.
ptrcao
ptrcao, Después de hacer la transferencia, ¿ha: (desmontado la unidad USB) o (utilizado la opción de expulsión / eliminación y esperó a que aparezca una ventana emergente que dice que puede quitarlo de manera segura)?
rozcietrzewiacz
Sí, eso es cuestión de costumbre. La única razón por la que no haría eso es en algunas redes, la función no está habilitada en el entorno de escritorio, pero parece recordar que esta función está disponible y la utilizo habitualmente en la red Linux en cuestión. Entonces, ¿qué te dice eso? ¿Algo útil?
ptrcao el
1
"Unidad H": apuesto a que el culpable está en el lado de Windows y no tiene nada que ver con Linux, la red o el servidor. El SMB de Windows parece tener algunos problemas como este, ya que intenta almacenar los archivos en el búfer internamente y desvincular el original (durante un 'movimiento') antes de finalizar.
Jonathan Cline IEEE

Respuestas:

11

Primero, nunca mueva un archivo a través de la red, solo copie. Siempre puede eliminar el original después de que la copia se haya completado con éxito. En segundo lugar, es posible que su sistema local ni siquiera sepa que existe una cuota del sistema de archivos en el almacenamiento remoto; no asuma que es posible adivinar con anticipación si una operación de copia fallará debido a una cuota remota. En lo que respecta al proceso de "envío", todos los bytes fueron enviados y recibidos por el extremo remoto, y usted quería mover el archivo para que ahora se pueda eliminar el original, desapareciendo el archivo poof .

"¿Alguna forma de recuperarse en el destino final?" - de ninguna manera. OK, tal vez uno pequeño. Verifique con el administrador de la red para ver si tal vez el sistema realmente recibió el archivo completo pero solo le informa el tamaño dentro de su cuota. No aguantes la respiración.

Y me disculpo si sueno un poco duro, pero parece que algunos hábitos nuevos están en orden. :-)

shon
fuente
No ... :( ¿Cómo podría el administrador no haberse protegido contra esto? Soy solo un estudiante normal, ¿qué sé sobre computadoras y redes y buenas prácticas de gestión de datos ... Me ha dado un rayo de esperanza. hice una solicitud y abrí un caso para ver si pueden recuperar mi archivo. ¿Alguna otra sugerencia útil, práctica, cosas que pueda hacer o pedir que haya hecho por mí? ¡Ese archivo fue importante y único! Lo necesito ... . :(
ptrcao
Además, en realidad intenté copiar el archivo remanente y ejecutarlo en casa. De hecho, es reportado como un archivo de 60Mb por todas las computadoras que lo ven, y de hecho ese archivo no es funcional. ¿Eso descarta tu escenario esperanzador?
ptrcao
¿Has hablado con un administrador del sistema? Esa es la única pizca de esperanza que queda.
shon
Si, no hay respuesta. :( Pero supongo que eventualmente lo
solucionarán
El administrador perezoso lo desestimó en un segundo y dijo que quería cerrar el caso. Fue instantáneo. Después de todos los detalles que he puesto en mi caso, no tanto como se molestó con ella ...
ptrcao
1

Solución de la vieja escuela para la próxima vez:

# sync
# sync
# sync
# umount /mnt

(Esto es algo sarcástico porque las tres sincronizaciones seguidas son heredadas y medio supersticiosas. Búscalo. Http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync )

Fue útil en los días de SYSV.

Ok, me llevó bastante tiempo localizar esto en google. (¿Por qué es tan difícil? ¿El folclore se pierde?) De todos modos, sugiero a los jóvenes que lean el libro de Unix Folklore de Raymond (que ... no puedo encontrar en Amazon ...).

Jonathan Cline IEEE
fuente
Je, eso me lleva de vuelta. Xenix ... Sincronización, espere a que el LED HDD se atenúe. Repita dos veces más y solicite la detención del sistema. ¿Alguien todavía sacrifica pollos en el teclado antes de comenzar cualquier actualización importante?
Fiasco Labs