¿Mac OS X no informa correctamente los tamaños de directorio?


17

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.


Tengo el presentimiento de que esto se reducirá a enlaces duros y enlaces simbólicos, y uno u otro de los que se convertirán en copias de archivo separadas cuando duplique esos paquetes .app. Por cierto, ¿los estás duplicando dentro del mismo volumen (partición?).
Spiff

¿Le falta algo a mi respuesta a continuación? Tengo la impresión de que es una respuesta completa a su pregunta, pero hasta ahora no ha habido ningún comentario suyo. ¿Me puede decir por favor?
Tonin

1
Me disculpo por el retraso. Tu respuesta llegó después de que perdiera interés en la pregunta. Pero su respuesta es excelente, muy detallada y de hecho responde completamente a mi pregunta. Muchas gracias, y tendré que recordar que el Finder muestra tamaños sin comprimir incluso si el archivo / carpeta está realmente comprimido.
pacoverflow

Vuelva a etiquetar esto, ¿tal vez debería haberlo etiquetado [copiar]? - Pero a expensas de qué otra etiqueta?
Arne Stenström

Respuestas:


13

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 informa dues 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 de cpcualquier 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):

antoine@amarante:/Applications$ du -ms iTunes.app/
281 iTunes.app/
antoine@amarante:/Applications$ cp -a iTunes.app/ iTunes-copy.app/
antoine@amarante:/Applications$ ditto iTunes.app/ iTunes-ditto.app
antoine@amarante:/Applications$ ditto --arch x86_64 iTunes.app/ iTunes-64.app
antoine@amarante:/Applications$ du -ms iTunes*
236 iTunes-64.app
289 iTunes-copy.app
281 iTunes-ditto.app
281 iTunes.app

Gracias a @DanPritts por su respuesta en mi publicación complementaria .


¿No es al revés? Finder muestra los prefijos SI reales.
Daniel Beck

¿No tendrían los archivos dispersos ( no paquetes dispersos / imágenes de OS X) un tamaño de archivo lógico mayor que el físico?
Daniel Beck

Sí, tienes razón, Finder muestra prefijos SI e duIEC, corregiré mi publicación.
Tonin

@DanielBeck Archivos dispersos, en teoría podría ser, sí, pero ¿qué tipo de archivos tendría una aplicación OSX como archivos dispersos? Según Wikipedia , los archivos dispersos no son compatibles con HFS +.
Tonin

Ese párrafo dice que es generalmente aplicable ( depende del tamaño real del sector / bloque del disco o del sistema de archivos ), por eso quería mencionar eso.
Daniel Beck

1

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.


Para volver a calcular los tamaños, seleccione Calcular todos los tamaños en las opciones de vista de carpeta. Ver apple.stackexchange.com/a/227173/156178
asmaier el

0

Esto es básicamente una suposición, pero veo dos posibilidades:

  1. Algunos datos se han eliminado pero no se han desasignado en el original, y esto no se ha copiado. Sin embargo, aparece en algunas búsquedas de uso de disco, pero no en otras (diferentes parámetros dados a du o lo que sea que OS X use internamente).
  2. Algunos datos se vinculan a la ubicación original, y esto afecta el tamaño percibido en diferentes herramientas.

Si (1) probablemente debería obtener resultados diferentes haciendo una tercera copia y comparando las copias.


Lo sentimos, no puedo hacer que los bloques de código multilínea se vean bien en un comentario, así que intentaré editar mi publicación original.
pacoverflow

No hubiera esperado que los duplicados fueran más grandes que el original: - / Parece digno de un informe de error, pero apuesto a que las posibilidades de recibir algún comentario sobre el funcionamiento interno de Finder causando que esto sea escaso. Sin embargo, espero que lo echen un vistazo.
elofturtle

0

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)

# cd /Applications/Calculator.app
# ls
Contents/

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)


-1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.