Tengo una carpeta (técnicamente en este caso, una imagen de disco montada de solo lectura) que contiene una tonelada de datos que obtuve al ejecutar Data Rescue (una aplicación de recuperación de datos) en una de mis grandes unidades de servidor. Hice varios tipos de escaneo diferentes y volqué todos los archivos en un solo lugar. Data Rescue 'reconstruye' los archivos eliminados y, a menudo, no lo hace del todo bien. Puede categorizar erróneamente el tipo de archivo que es y puede combinar archivos separados.
Estoy buscando dos archivos PHP específicos (y tal vez unos 5 más si tengo suerte). La mayoría de estos archivos recuperados no tienen nombres (0002, 0003, etc.), así que tengo que buscar por contenido.
Se me ocurrieron 6 cadenas diferentes que deberían poder identificar estos archivos específicos. Así que necesito una forma de buscar el contenido de los archivos, no en una "búsqueda mágica" de Apple, sino en una vieja escuela "leer manualmente cada archivo buscando una coincidencia de cadena".
grep
suena como la elección obvia, pero no ha sido más que problemas. grep puede buscar recursivamente y puede descomprimir archivos gzip, zip y bzip, lo cual es bueno. Pero después de unos minutos de ejecución, comienza a transmitir errores de "demasiados archivos abiertos". No estoy seguro de por qué, es como si grep no cerrara un archivo después de abrirlo para buscarlo. También he tenido problemas con grep
solo detenerme... no cerrar, no fallar, no dejar de responder, pero no usar más CPU, no leer nada del disco, simplemente permanecer inactivo cuando debería estar buscando. TAMBIÉN tuve problemas para ejecutar varias grep
búsquedas a la vez.grep
parece cargar archivos línea por línea, por lo que algo así como una imagen de disco carga todo en la memoria antes de buscar. Pero solo hay un archivo en todo este paquete que es más grande que la cantidad de RAM que tengo. Entonces, mientras haga uno grep
a la vez, debería estar bien.
Este es el comando que estoy usando (envuelto en un script que ejecuta varios comandos en diferentes archivos de salida, con algunos estados de salida):zfgrep -l -r -a -J -i -s -U -n "#32cd32" /Volumes/\'Storage\'\ Original\ Recovery > 32cd32.txt
Esto se ejecutará durante un tiempo, luego se colgará. Obtendré algunos resultados, pero no una búsqueda completa. Si elimino el -s
, obtengo una avalancha de too many open files
errores. Luego, por sugerencia de otra persona, acostumbro find
a alimentar los archivos de grep
uno en uno, así:
find /Volumes/\'Storage\'\ Original\ Recovery -exec zfgrep -l -r -a -J -i -s -U -n "#32cd32" {} \; -print > 32cd32.txt
Pero ese comando tiene exactamente los mismos problemas.
Así que esto me deja atascado. ¿Cómo puedo buscar en cada archivo de esta imagen de disco, incluidos los archivos comprimidos, algunas cadenas de texto sin formato? ¿Incluyendo archivos de datos binarios que pueden haberse fusionado incorrectamente con archivos de texto sin formato? Esto no parece una tarea tan difícil para una computadora multinúcleo moderna con un sistema operativo actual, mucha RAM y un SSD.
De hecho, preferiría una opción de GUI, pero en este punto tomaré cualquier solución que funcione.
También originalmente comencé a intentar hacer esto usando BBEdit, pero saltaba MUCHOS tipos de archivos incluso cuando le decías que buscara todos los archivos. Incluso archivos basados en XML. Me sorprendió mucho esto.
El uso find ... -exec grep -r
recorre efectivamente todo el directorio varias veces (una como parte de find
, una vez como parte de cada grep -r
), lo que puede generar los errores que ve. Así que deberías deshacerte del find
o del -r
. Como usa la grep
parte para identificar los archivos que se van a recopilar, es probable que sea -r
en su caso.
sin ladera
grep
es el camino a seguir aquí. ¿ Estás segurogrep
de que el problema está aquí? ¿Qué sucede si ejecutafind /... -print
, se ejecuta o finaliza también? Y definitivamente no deberías obtenerlotoo many open files
si lo usas.find ... -exec grep
¿Puedes, por favor, para ambos comandos, copiar/pegar directamente desde la Terminal para que veamos lo que ves?sin ladera
grep -r
si usafind
, de lo contrario, atraviesa los subdirectorios dos veces (y obtiene el error dezfgrep
).Nimesh Neema
sin ladera
l008com
-type f
al comando de búsqueda para que omita directorios.l008com
l008com
Xcode
, pero sé tan poco al respecto que no llegué muy lejos. Intenté volcar todos los archivos, pero estaba intentando indexarlos a todos. Una búsqueda basada en índices no funcionará para esto porque el tipo de contenido que estoy buscando probablemente no se indexe, ya que no son 'palabras' reales. Además, dejé 370 000 archivos allí, pero solo estaba escaneando 30 000 de ellos. Claramente estoy fuera de mi elemento allí, pero espero que estofind/grep
funcione.fd0
-print
primario de su declaración de búsqueda. Simplemente está repitiendo los resultados degrep
.l008com
Natsfán