Debido a un problema con la sincronización de los contactos (no estoy seguro de cuál fue el origen del problema, probablemente una caída del programa en el corte de energía, que causó inconsistencia en el archivo de la base de datos de los contactos), el proceso de sincronización creó casi 7M de archivos en Images/ :
hostname:Images username$ pwd
/Users/username/Library/Application Support/AddressBook/Sources/4D81D34B-C932-4578-8A31-4E2E244B3875/Images
hostname:Images username$ ls
^C
hostname:Images username$ ls | wc -l
6797073
(the result was after hours)
hostname:Images username$ cd ..
hostname:4D81D34B-C932-4578-8A31-4E2E244B3875 username$ ls -l
total 600224
-rw-r--r--@ 1 username staff 409600 Aug 2 17:43 AddressBook-v22.abcddb
-rw-r--r--@ 1 username staff 32768 Aug 3 00:13 AddressBook-v22.abcddb-shm
-rw-r--r--@ 1 username staff 2727472 Aug 2 23:26 AddressBook-v22.abcddb-wal
drwx------ 65535 username staff 231100550 Aug 2 23:26 Images
-rw-r--r--@ 1 username staff 45056 Dec 7 2017 MailRecents-v4.abcdmr
-rw-r--r--@ 1 username staff 32768 Dec 7 2017 MailRecents-v4.abcdmr-shm
-rw-r--r--@ 1 username staff 4152 Dec 7 2017 MailRecents-v4.abcdmr-wal
drwx------ 5 username staff 170 Feb 26 18:51 Metadata
-rwxr-xr-x 1 username staff 0 Dec 7 2017 OfflineDeletedItems.plist.lockfile
-rwxr-xr-x 1 username staff 0 Dec 7 2017 Sync.lockfile
-rwxr-xr-x 1 username staff 0 Dec 7 2017 SyncOperations.plist.lockfileCuando intenté utilizar las herramientas del shell ( ls , find ), no obtuve ningún resultado en tiempo razonable para el trabajo interactivo (fueron horas), independientemente de desactivar la clasificación de archivos como ls -f (lo que parece ayudar en el caso de otros sistemas operativos tipo UNIX ), etc. El ls ha crecido hasta alrededor de 1GB de tamaño y ha trabajado durante HORAS antes de dar algún resultado. Mi pregunta es: ¿me falta alguna opción complicada para que esto funcione de forma razonable para directorios grandes (con salida de los resultados en el camino, por ejemplo, para procesar más, filtrar, etc.) o estas herramientas simplemente no están escritas a escala? ¿O tal vez hay mejores utilidades de archivo/directorio para MacOSX? (No he probado ninguna aplicación GUI en ese directorio, pensando que es mejor no hacerlo...).
He escrito un programa en C bastante trivial que lee las entradas de los directorios y que emite la información en el camino:
#include <dirent.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/param.h>
#include <unistd.h>
int main ( const int argc,
const char * const * argv )
{
const char * const dirpath = argv[1];
DIR *dirp = opendir ( dirpath );
if ( dirp == NULL )
return (-1);
int count = 0;
struct stat statbuf;
for ( struct dirent *entry = readdir ( dirp ) ;
entry != NULL ;
entry = readdir ( dirp ), count++ )
{
char filepath [ PATH_MAX + 1 ];
memset ( filepath, 0, PATH_MAX );
strncat ( filepath, dirpath, PATH_MAX );
strncat ( filepath, "/", PATH_MAX );
strncat ( filepath, entry->d_name, PATH_MAX );
stat ( filepath, &statbuf );
printf ("%s %llu\n", entry->d_name, statbuf.st_size );
}
closedir ( dirp );
printf ("%d", count );
return 0;
}que realmente funciona (muestra el resultado después de leer cada entrada) y tiene una huella de memoria de alrededor de 300K. Así que no es un problema del sistema operativo (sistema de archivos, controlador, biblioteca estándar o lo que sea), sino de las herramientas que básicamente no escalan bien (sé que soportan más opciones, etc., pero para un listado de directorios básico, sin ordenar ni nada de fantasía ls debería funcionar mejor, es decir, no asignar 1GB de memoria, mientras que find debería hacer la acción para cada entrada que encuentra (y coincide), no leerlas todas primero, como aparentemente hace...).
¿Alguien ha experimentado esto y tiene una buena solución para lidiar con directorios tan grandes (qué utilidades usar) en MacOSX? (¿O quizás sea necesario escribir alguna utilidad de sistema personalizada en este caso?)
(Es una situación excepcional, por supuesto, ocurrió por primera vez en mi sistema - pero el sistema operativo soporta directorios tan grandes, y las herramientas básicas del shell deberían tratar con ellos en un razonable manera...)
EDITAR: Pequeña corrección en el programa (a la ruta del archivo le faltaba '/').
