¿Por qué /tmp es un enlace simbólico a /private/tmp?

Según tengo entendido, es un vestigio de NextStep (en el que se basa OS X), y NextStep lo hizo para admitir NetBooting. La idea era que se pudiera iniciar desde un volumen alojado en la red (probablemente de solo lectura y ciertamente compartido con otras computadoras) y, al principio del proceso de inicio, montar un volumen local (de escritura) en /private; como g mencionó, esto permitió la modificación del tiempo de ejecución de /var y /tmp, así como la configuración por computadora en /etc.

Esto ya no es necesario, ya que el sistema NetBoot actual de Apple usa una imagen de disco oculta para almacenar cambios en cualquier parte del volumen de arranque. Pero algunos programas/docs/etc ahora asumen que los archivos se encuentran en /private, por lo que sería demasiado problema volver a cambiarlos...

Actualización: desde que escribí esto, Apple ha dejado de admitir NetBoot, por lo que el propósito original de /private es aún más obsoleto. Sin embargo, en macOS Catalina (versión 10.15), agregaron una nueva división de volumen. En este caso, es más por seguridad que por compatibilidad con NetBoot, pero funciona de manera bastante similar.

El volumen del sistema de Catalina está montado como de solo lectura, con un volumen de lectura y escritura montado en /System/Library/Data (análogo al sistema antiguo que montaba un volumen RW en /private) y "firmlinks" que hacen que aparezcan partes del volumen RW en sus ubicaciones habituales en el sistema de archivos (nuevamente, de forma análoga a los enlaces simbólicos que hacen que partes de /private aparezcan en sus ubicaciones habituales). Por ejemplo, /Users ahora es un vínculo firme a /System/Library/Data/Users. The Eclectic Light Company tiene un buen resumen .

Catalina también tiene los enlaces simbólicos a /private; por lo tanto, cuando accede a /etc en Catalina, sigue el enlace simbólico a /private/etc, y luego el enlace firme a /System/Library/Data/private/etc

Siempre me he preguntado lo mismo. No puedo encontrar ninguna documentación que lo respalde, pero normalmente este patrón se usa para facilitar el almacenamiento de archivos en otro volumen (por ejemplo, disco duro). Esto permite que la unidad se monte (por ejemplo, se adjunte) en el sistema de archivos en un solo lugar. Por ejemplo, cuando la unidad está montada en /privatey luego las carpetas /etc, /tmpy /varestán todas ubicadas en esa otra unidad.

Lo que no puedo decir es por qué esto sería beneficioso. Sin embargo, vale la pena señalar que estas tres carpetas contienen archivos de "datos" como archivos de configuración, temporales, de registro, transitorios y de base de datos en lugar del código ejecutable contenido en las carpetas /bin, /sbiny ./usr

No estoy seguro de la razón histórica, pero OS X siempre "reorganizó" la estructura típica de Unix. /tmpno es lo único que va a /private, también tiene /etcy /var.

Tal vez a alguien con más experiencia en OS X se le ocurra algo más razonable.

/tmpes un enlace simbólico /private/etcpara mantener 2 sistemas de archivos claramente separados:

• /que se puede montar como de solo lectura, para protegerlo contra cualquier modificación accidental o no deseada, y para protegerlo de que se llene con archivos cada vez mayores (logs y archivos temporales),

• /privateque se pueden montar como lectura-escritura y que contienen cualquier directorio que contenga archivos modificables.

Si observa /, notará 3 directorios que son enlaces simbólicos similares por la misma razón:

cd /
ls -al | grep '> private'

Esta separación de acceso entre sistemas de archivos de lectura-escritura y de solo lectura no se usa en realidad (en MacOS X), pero todo está en su lugar para lograr esta separación de seguridad.

Algunos administradores imponen esta separación de seguridad definiendo un /privatesistema de archivos específico con el tamaño adecuado y las opciones de montaje adecuadas (sobre todo nosuid).

Con frecuencia en Unix, las formas idénticas de lo mismo se deben a las diferencias históricas entre System V Unix y BSD Unix. Los Unix modernos tienen que soportar ambos para ser compatibles.

Por ejemplo, lpry lppara imprimir: lpres de BSD y lpes de System V.

Si este es el caso aquí, no lo sé.