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

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$ 

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. :-)

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 ...).

• http://groups.google.com/group/alt.folklore.computers/browse_thread/thread/2481588b2317173b/576619b0a9498186