Estoy en una computadora portátil Win10 y tengo el siguiente problema:
Cifré una carpeta que incluye todas las subcarpetas usando la función de cifrado incorporada que obtienes cuando haces clic derecho en una carpeta> propiedades> avanzado.
Moví una subcarpeta de esta carpeta que contenía algunos archivos .cpp a una unidad USB (FAT32) y desde allí a un HD de Linux (EXT3/EXT4) sin darme cuenta de que todavía estaba encriptado.
En mi PC con Linux obviamente no podía abrir esos archivos porque tenían la extensión .pfile y estaban cifrados. Entonces los moví nuevamente a la unidad USB y de allí nuevamente a la computadora portátil.
Sin embargo, en el cuaderno ahora tampoco puedo abrirlos. Parece que Win10 ni siquiera se da cuenta de que todavía están cifrados, porque ese enlace en las propiedades ya no está configurado.
Lo instalé usando Azure Information Protection-Viewer pero solo aparece un error que indica que no se puede abrir el tipo de archivo (.cpp). (No sé la notificación de error exacta en inglés porque no estoy en una instalación en inglés)
Respuesta1
Parece que Microsoft está utilizando campos no utilizados anteriormente en las entradas del directorio FAT32 y posiblemente también entradas de directorio ocultas y trucos con nombres de archivos largos y cortos para almacenar metadatos EFS en FAT32:
Los archivos cifrados tienen la extensión ".PFILE" y sus entradas de directorio 8.3 almacenan metadatos adicionales. En la implementación actual, estos metadatos se ajustan a 6 bits: dos bits se utilizan como indicadores y cuatro bits para almacenar el tamaño del relleno.
Los metadatos adicionales se almacenan en el campo NTByte, que se encuentra en el desplazamiento de 12 bytes dentro de la entrada del directorio 8.3. Anteriormente, este campo solo se usaba para almacenar dos indicadores que marcaban el nombre base corto o la extensión en minúsculas (bits #3 y #4 respectivamente).
Ahora también se utilizan los bits restantes. El bit #0 se establece cuando el archivo está cifrado (también se establece para un directorio cuando sus archivos recién creados deben cifrarse de forma predeterminada), el bit #1 se establece cuando el archivo comienza con un encabezado EFS grande (de lo contrario, es un EFS estándar encabezamiento). Otros bits (bits #2, #5, #6 y #7) se usan para almacenar el tamaño del relleno (que tiene un tamaño máximo de 15 bytes, por lo que 4 bits son suficientes): su bit #0 (LSB) va a bit #2 del campo NTByte, bit #1 al bit #5, bit #2 al bit #6, bit #3 al bit #7.
(Fuente, ver también el referenciadoPatente estadounidense US10726147B2)
Al quitar los archivos y luego volver a colocarlos, se destruyen los metadatos especiales, porque Linux no lo sabe.
Lamento decir esto, pero es casi seguro que sus archivos ya no se pueden recuperar. Aún así, puedes intentar adivinar los metadatos ocultos; después de todo, solo hay 64 valores posibles. Sin embargo, hacer esto requeriría un editor hexadecimal de disco sin formato o un controlador de sistema de archivos personalizado.
Respuesta2
Después de días de búsqueda encontré la solución,
El problema es que cuando copias archivos a Linux y los vuelves a copiar, los metadatos de los archivos destruidos, lo soluciono usando Disk Editor, creé un archivo del mismo tamaño, lo cifré y lo copié en la unidad FAT32 y copié los metadatos del archivo. después de eliminarlo y reemplazarlo con el ".PFILE" destruido y reemplazar los metadatos
Gracias "Daniel B" tu respuesta realmente me ayudó