Los .crdownload olvidados: cómo saber si perdí datos (o solo la calma)

El otro día estaba revisando las copias de seguridad que tenía en un disco que me encontré abandonado al fondo del cajón.

Navegando entre sus ficheros me encontré 9 zips de una exportación de google que hice hace varios años (Takeout). Pero también me encontré algo más: 4 ficheros Sin confirmar*.crdownload. Fuck.

¿Tenía toda la copia completa o me faltaban partes o datos que no se llegaron a exportar?

Lista de ficheros donde se aprecian 4 descargas incompletas

Qué son los .crdownloads

Los .crdownloads son ficheros temporales de Chromium que se crean siempre cuando vas a descargar cualquier cosa de internet. Es el paso intermedio entre que le das a descargar, y cuando ya lo tienes listo con el nombre definitivo.

En estos ficheros es donde el navegador guarda temporalmente los datos de la descarga. Cuándo termina, se “renombra” a su versión definitiva.

Verificación

Como te imaginas, estos ficheros no se pueden abrir para ver que tienen como si nada porque no forman un fichero válido. No están completos y son solo una amalgama de bits.

Pero somos ingenieros. Los bits no nos asustan.

Una opción que tenemos es leer los primeros bytes de cada .crdownload y buscar si pertenece a algún fichero de los que tenemos completos. Si encontramos una coincidencia, entonces será seguro borrarlo sabiendo que en realidad ya tenemos esos datos.

Si no encontramos ninguna, entonces esa descarga efectivamente correspondía a datos que no tenemos, y tendré que volver a descargarlo todo. Es broma. Seguramente haya perdido todo lo que no tuviera ya.

Comparando hashes

Para “ver” los primeros bytes de un fichero podemos usar head. Pero esto no es nada glamuroso ni cómodo de comparar, por lo que podemos obtener el md5. Comparar bytes es un rollo. Comparar hashes cortos no tanto.

Podemos hacer esto con head -c 10M <file> | md5sum. En ese ejemplo obtendremos el md5 de los primeros 10MB de .

¿Por qué 10MB? Porque en este caso es un buen equilibrio entre probabilidad de coincidencia y coste de cálculo… bueno, en el fondo incluso medio mega hubiera bastado (o menor si los ficheros fueran más pequeños).

Como tengo 4 ficheros que podría corresponder (o no) a alguno de los 9 zips, lo mejor para automatizarlo y no comprobarlos mano a mano es automatizarlo en 2 pasos:

  1. Generar los hashes:

     # Para los ZIPs
     for f in takeout-*.zip; do
         head -c 10M "$f" | md5sum | cut -d' ' -f1 > "$f.head"
     done
    
     # Para los crdownload
     for f in *.crdownload; do
         head -c 10M "$f" | md5sum | cut -d' ' -f1 > "$f.head"
     done
  2. Comparar los hashes:

    for f in *.crdownload.head; do h=$(cat "$f"); for z in *.zip.head; do if [[ "$h" == "$(cat "$z")" ]]; then echo "COINCIDENCIA: '$f' es el inicio de '$z'"; fi; done; done

Si el número de coincidencias cuadra con nuestros sospechosos, podemos respirar tranquilos: esos archivos no son datos perdidos, sino simples ecos de una descarga que ya tenemos a salvo.

Los hashes coinciden

¿Por qué seguían ahí? Seguramente el proceso falló, tuve que reintentar la descarga varias veces y el navegador nunca hizo limpieza. O quizás mi yo del pasado pensó que sería muy divertido dejarle este acertijo a mi yo del futuro. Qué cabrón.