En Finder, noté que si duplico algunos archivos .app (en la carpeta Aplicaciones), Finder mostrará que el archivo .app duplicado no tiene el mismo tamaño que el original. Esta discrepancia de tamaño de archivo no ocurre para todos los archivos .app que duplico, pero parece que cuanto más grande es el archivo .app, es más probable que el duplicado no muestre el mismo tamaño que el original. Aquí hay unos ejemplos:
GarageBand.app - 381.7 MB
GarageBand copy.app - 373.2 MB
iMovie.app - 695.3 MB
iMovie copy.app - 635.4 MB
Install Xcode.app - 1.81 GB
Install Xcode copy.app - 1.57 GB
Ahora soy nuevo en Mac, y después de notar este problema de discrepancia de tamaño de archivo, descubrí que los archivos .app en realidad no son archivos, en realidad son directorios, pero Finder los muestra como si fueran archivos. Así que pensé que tal vez el proceso de duplicación no copiaba todo el contenido del directorio .app original y eso explicaba la diferencia en el "tamaño del archivo". Pero luego descargué e instalé DeltaWalker, que es una herramienta de diferencia de archivos / carpetas, y DeltaWalker dijo que los directorios .app duplicados eran exactamente iguales a los directorios .app originales. Por lo tanto, el proceso de duplicación funcionó perfectamente y, por lo tanto, parece ser un problema con el tamaño de los archivos de informes del Finder.
También verifiqué los tamaños de los directorios en Terminal, usando el comando "du", y eso también muestra discrepancias en los tamaños entre los directorios originales y duplicados:
du -k /Applications/GarageBand.app/
212868 /Applications/GarageBand.app/
du -k /Applications/GarageBand\ copy.app/
397880 /Applications/GarageBand copy.app/
du -k /Applications/iMovie.app/
629644 /Applications/iMovie.app/
du -k /Applications/iMovie\ copy.app/
700500 /Applications/iMovie copy.app/
du -k /Applications/Install\ Xcode.app/
1771864 /Applications/Install Xcode.app/
du -k /Applications/Install\ Xcode\ copy.app/
1772228 /Applications/Install Xcode copy.app/
Además, no se trata solo de directorios .app. Dupliqué mi directorio / Developer / Library, y esto es lo que du dijo:
du -k /Developer/Library/
320784 /Developer/Library/
du -k /Developer/Library\ copy/
399868 /Developer/Library copy/
Entonces, ¿alguien puede explicar por qué Mac OS X no parece informar los tamaños de directorio correctamente? ¿Es un error (difícil de creer por algo tan simple) o me falta algo (ser un nuevo usuario de Mac)?
(Estoy ejecutando Mac OS X Lion 10.7.2)
ACTUALIZACIÓN en respuesta a elofturtle:
Lo más extraño de esto es que Finder no tiene consistencia. Acabo de hacer 2 duplicados de GarageBand.app, y luego hice 2 duplicados de uno de los duplicados. Finder muestra cada duplicado con un tamaño diferente:
GarageBand.app - 381.7 MB
GarageBand copy.app - 357.6 MB (duplicate of GarageBand.app)
GarageBand copy 2.app - 353.9 MB (duplicate of GarageBand.app)
GarageBand copy 3.app - 378.2 MB (duplicate of GarageBand copy 2.app)
GarageBand copy 4.app - 329.1 MB (duplicate of GarageBand copy 2.app)
También tenga en cuenta que "GarageBand copy 3.app" es más grande que "GarageBand copy 2.app", mientras que "GarageBand copy 4.app" es más pequeño que "GarageBand copy 2.app". Eso tiene que ser un error en Finder.
Esto es lo que dice "du -k" sobre todos ellos:
212868 /Applications/GarageBand.app/
397880 /Applications/GarageBand copy.app/
397880 /Applications/GarageBand copy 2.app/
397880 /Applications/GarageBand copy 3.app/
397880 /Applications/GarageBand copy 4.app/
Al menos dice que todos los duplicados son del mismo tamaño, pero no son del mismo tamaño que el original.
fuente
Respuestas:
Las diferencias provienen de diferentes razones: diferentes formas de contar, diferentes herramientas, compresión y lo que parece un error.
La primera diferencia de tamaño que ves parece ser un error en el Finder . Los tamaños de archivo que muestra el Finder se calculan de alguna manera en tiempo real y se almacenan en caché en los
.DS_Storearchivos. Por alguna razón, al duplicar una gran aplicación / carpeta, el Finder calcula su tamaño durante el proceso de copia y almacena en caché el tamaño, luego incompleto. Luego muestra que el tamaño está atenuado en las ventanas del Finder, gris, lo que significa que el Finder sabe que el contenido ha cambiado desde su último cálculo de tamaño, pero aún no lo ha recalculado .La única forma en que he encontrado para que vuelva a calcular correctamente el tamaño es eliminando el
.DS_Storearchivo en la carpeta de la aplicación, luego saliendo del Finder (desde el Monitor de actividad, por ejemplo) y reiniciando nuevamente (desde el Icono del Dock). Si no elimina el.DS_Storearchivo, aún permanece atenuado. Tal vez esperar un tiempo (horas, días, reiniciar, ...) hará que el Finder lo haga solo.Después de eso, debería ver que todos los tamaños informados por el Finder son los mismos.
Entonces, sí, parece un error de Finder, al menos en OSX Lion (probado con 10.7.4 aquí, Finder versión 10.7.3). También puede ver este hilo que informa el mismo tipo de comportamiento.
Entonces, consideremos la
duherramienta. Al principio, pensé que la diferencia que vemos podría explicarse por la diferencia entre los tamaños lógicos y físicos de los elementos que se copian. El tamaño lógico es el tamaño real del elemento, lo que significa que cada bit de información que contiene se suma. El tamaño físico es el tamaño del elemento en el disco, donde cada bit de información se escribe en un sector de disco.Por ejemplo, un archivo que contiene un solo carácter terminaría teniendo un tamaño lógico de 1 byte, pero un tamaño físico de 512 bytes o incluso 4096 bytes cuando realmente se escribe en el disco. El tamaño físico suele ser mayor que el tamaño lógico (y depende del tamaño real del sector / bloque del disco o del sistema de archivos). Esto se explica con más detalles en este otro hilo . El tamaño lógico podría ser mayor en el caso de archivos dispersos , pero HFS + no parece admitir tal característica.
dumuestra solo el tamaño físico (y puedes decirle qué es BLOCKSIZE). Puede ver que el tamaño que informadues siempre mayor (o, excepcionalmente, el mismo) que el original. Esto se debe a la fragmentación del sistema de archivos y el espacio en disco. Cuando copia sobre un archivo (en realidad aquí hay un montón de archivos, ya que una Aplicación es un directorio), se asignan nuevos sectores en el disco y, a medida que se produce la fragmentación , el número de bloques utilizados suele ser mayor que el del elemento original. Algunas personas lo llaman File Slack .Ahora, de vuelta al buscador. Si abre la ventana de obtener información de las aplicaciones que ha duplicado, verá que el Finder informa realmente el tamaño lógico y físico del elemento que seleccionó. Lo que entonces tiene sentido. Incluso podrá comparar el tamaño físico informado por el Finder y el que informa
dusi hace un poco de matemática.¿Por qué hacer algo de matemáticas? Porque el Finder muestra los tamaños de archivo en kB, MB o GB donde los
duinforma en kiB, MiB o GiB. Esos son los prefijos binarios de IEC que deben usarse para calcular y mostrar unidades de información digital.Pero, en realidad, no estoy seguro de que File Slack esté involucrado aquí, hay algo más. Los volúmenes HFS + permiten la compresión , de forma transparente, y Apple la usa para los elementos originales instalados por el sistema operativo. Luego, cuando los archivos se copian con herramientas estándar, la compresión ya no se usa (de forma predeterminada, para ser compatible con versiones anteriores). Si desea mantener la compresión en esos archivos, debe usar el
dittocomando en lugar decpcualquier acción del Finder. Esto se explica en esta revisión .Aquí está el resultado de copiar iTunes.app usando las diferentes técnicas. Verá que lo mismo hace que la aplicación tenga exactamente el mismo tamaño, preservando la compresión, donde
cpno lo hace. E incluso puede eliminar el binario para el arco que no necesita, y luego reducir el tamaño completo):Gracias a @DanPritts por su respuesta en mi publicación complementaria .
fuente
duIEC, corregiré mi publicación.Es una falla / error horrible en OS X. La forma más fácil de verlo es duplicar un paquete de aplicaciones grande, luego mostrar el contenido y eliminar un archivo enorme desde dentro. El espacio no se recuperará. El archivo sigue siendo enorme. Por ejemplo, si tiene un paquete de aplicaciones de 3.5GB, muestra el contenido, luego elimina 3GB de él, ahora debería tener una aplicación con un tamaño de archivo de 500MB. No lo harás. Seguirá siendo de 3.5GB.
fuente
Esto es básicamente una suposición, pero veo dos posibilidades:
Si (1) probablemente debería obtener resultados diferentes haciendo una tercera copia y comparando las copias.
fuente
En primer lugar, debe tener en cuenta que los archivos .app de Mac son en realidad Directorios , no archivos binarios compilados como archivos .exe de Windows. El Finder solo te oculta este hecho para las carpetas llamadas * .app.
por ejemplo (desde la terminal)
Estoy bastante seguro de que lo que está sucediendo es que Finder / Get Info está utilizando una heurística no muy inteligente para calcular el tamaño de la carpeta .app. Esto significa que no es necesario enumerar cada subcarpeta y archivo y agregar todos esos tamaños.
Supongo que la estimación de la copia es correcta porque OSX recientemente tuvo que inspeccionar todos los archivos que contenía cuando hizo la copia, mientras que en el original, OSX nunca tuvo que hacerlo (por ejemplo, con instalaciones de fábrica)
fuente
Tuve este problema con mi Home Directory una vez que lo moví a un HDD interno después de instalar Yosemite en el SSD. Al usar 'Obtener información', informó un tamaño incorrecto de solo 8 GB, aunque mostró el tamaño correcto de 240 GB en la barra de estado del Finder. Lo arreglé haciendo clic en Obtener información en la carpeta Usuarios, que luego calculó correctamente y arregló el tamaño incorrecto que informa Home Directory.
fuente