El origen de .DS_Store (2006)

 (arno.org)
3 puntos por GN⁺ 2024-07-04 | 1 comentarios | Compartir por WhatsApp
  • .DS_Store es la abreviatura de Desktop Services Store, surgida al rehacer Finder para Mac OS X en 1999
  • En ese momento, la base de código de Finder tenía unos 8 años, así que incluso cambios pequeños costaban mucho y rompían funciones que parecían no tener relación, por lo que fue necesaria una reescritura completa
  • El nuevo Finder separó la interfaz de usuario del backend, y el backend se encargaba de la enumeración de archivos, la supervisión de cambios y los metadatos como la posición de los íconos y la configuración de carpetas
  • El backend de Finder se convirtió en candidato para una API pública utilizable también fuera de Finder y, junto con la idea de renombrar Finder como “Desktop”, recibió el nombre de Desktop Services
  • .DS_Store originalmente solo debía crearse al cambiar la configuración de vista o la posición de los íconos, pero por un bug muchas veces se genera con solo visitar una carpeta

El nacimiento del nombre Desktop Services Store

  • En 1999, cuando Apple estaba creando de nuevo Finder para Mac OS X, la base de código existente de Finder tenía unos 8 años
    • Hacer cambios requería un gran esfuerzo de ingeniería
    • Los cambios solían romper 2 o 3 funciones que aparentemente no tenían relación
    • Se decidió reescribir Finder para Mac OS X desde cero
  • Durante la reescritura, se separaron la interfaz de usuario y el backend central de Finder
    • Sus nombres internos eran Finder_FE y Finder_BE, respectivamente
    • El backend se encargaba de la enumeración de archivos, la supervisión de cambios del sistema de archivos, el manejo de metadatos, la posición de los íconos y la configuración de carpetas
  • Como el backend de Finder también podía ser útil fuera de Finder, surgió el plan de ofrecerlo algún día como API pública
    • Basándose en la experiencia previa de haber nombrado Icon Services y Navigation Services, se eligió el nombre Desktop Services
    • En ese momento también se estaba considerando renombrar Finder como “Desktop”
    • .DS_Store viene de “Desktop Services Store”
    • El . inicial se eligió para que se tratara como un archivo invisible en sistemas tipo Unix y en Mac OS

Condiciones de creación e impacto posterior

  • El nombre podría haber sido más descriptivo, pero una vez que ya se había usado ampliamente, resultaba difícil cambiarlo
  • El archivo .DS_Store originalmente solo debía crearse cuando el usuario ajustaba la configuración de vista de una carpeta o asignaba manualmente la posición de los íconos
    • Sin embargo, debido a un bug que no se corrigió, el archivo se crea en exceso
    • En la práctica, está casi garantizado que se genere un archivo .DS_Store con solo visitar una carpeta
  • Finder_BE, es decir, Desktop Services, también se usó fuera de Finder
    • Navigation Services, es decir, los cuadros de diálogo de abrir/guardar, también terminó usándolo después
    • En las primeras versiones de Mac OS, Navigation Services no lo usaba
    • La Desktop Services API todavía no se ha hecho completamente pública

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-04
Opiniones de Hacker News

  • Además de este archivo, también hubo momentos de confusión por el concepto de fork en el sistema de archivos de Mac.
    Aquí, fork no se refiere a fork(), sino a una estructura dentro del sistema de archivos donde existían en par un componente de datos y un componente de recursos; uno se trataba como metadatos y el otro como el contenido del archivo.
    En Unix, los metadatos estaban del lado de los bloques de directorio y los inodes, y no estaban vinculados de forma única al archivo, así que estructuras como tar, cpio y zip tenían que representarlos por separado.
    Para implementar en Unix soporte para archivos compatibles con Mac, había que tratar el resource fork como datos de primera clase, y la forma natural era poner un archivo como .file junto a cada archivo.
    En ese entonces, el bloque de inode de UFS no podía mapear todos los atributos del resource fork, y ahí también iban cosas como los íconos. Los sistemas de archivos más modernos tienen estructuras de bloques de directorio más grandes, por lo que pueden manejar mejor esos datos.

    • Creo que describirlo como “uno son metadatos y el otro es el contenido del archivo” no es preciso para explicar el resource fork.
      Más bien, lo correcto es verlo como dos conjuntos de contenido de archivo: uno se llamaba data y el otro rsrc, y en el disco ambos eran simplemente flujos de bytes.
      Sin embargo, el resource fork normalmente almacenaba una estructura de pequeños fragmentos de datos indexados por un código de tipo de 4 bytes y un ID entero de 2 bytes.
      Las aplicaciones de Mac 68K ponían casi todo en el resource fork: código, menús, cuadros de diálogo, imágenes, íconos, cadenas, etc.; si copiabas una app vieja de Mac a una PC o a Unix sin convertirla, parecía un archivo vacío.
      Por eso, para enviar apps de Mac por la red había que codificarlas como un solo flujo; al principio se usaban BinHex .hqx o MacBinary .bin, y más tarde archivos Stuffit .sit.
      La razón por la que esta estructura no encaja en un inode es que, en la práctica, sería como intentar meter un archivo entero ahí a la fuerza. La estructura del resource fork en sí tenía un límite de 16 MB, pero si se trataba como un flujo de datos separado podía hacerse tan grande como se quisiera.
    • Recuerdo que en el resource fork estaban las cosas que antes se editaban con ResEdit. Íconos, varios recursos de GUI, y también podían ser texto y recursos de traducción.
      Por ejemplo, los plugins de Escape Velocity usaban tipos de recursos personalizados y se podían editar fácilmente con un plugin de ResEdit.
    • NTFS también tiene flujos de datos alternativos (Alternate Data Streams), pero creo que casi no se usan.
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • Los metadatos de la aplicación, como los formatos de archivo que una aplicación podía abrir o qué ícono usar cuando coincidía con el creator code de la aplicación, se guardaban en el resource fork de esa aplicación, pero los metadatos del archivo no se guardaban en el resource fork.
      El tipo de archivo, el creator code, los bits de bloqueo, invisible, bozo, etc., siempre se guardaban en el sistema de archivos.
      Por ejemplo, se puede ver la descripción del formato de disco MFS: https://wiki.osdev.org/MFS#File_Directory_Blocks
    • Por los datos en forks, hacer CD/DVD de doble formato era bastante interesante. Al principio era una especie de truco, pero más adelante el software de grabación para Mac lo manejaba fácilmente.
      Crear un DVD de arranque para Mac tampoco era precisamente trivial.

  • Recuerdo que antes había una forma de desactivar la creación de .DS_Store, pero Apple la quitó, y no entiendo para nada por qué hizo ese cambio.
    Al final terminé escribiendo yo mismo un programa que vigilaba todo el sistema de archivos y borraba los .DS_Store apenas aparecían.
    [0] https://github.com/slmjkdbtl/dskill

    • Se puede desactivar en volúmenes de red.
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      No recuerdo que alguna vez haya existido una forma de desactivarlo en volúmenes locales.
    • Apple realmente hizo un desastre cuando empezó a crear archivos que comienzan con . en la raíz del sistema de archivos.
      Después de que se permitió .DS_Store, parece que otros ingenieros aprobaron fácilmente cosas como .fseventsd y .Spotlight-V100.
      Ni sé cuántos sistemas de archivos “contaminados” he visto por culpa de estos archivos. Principalmente eran tarjetas SD o memorias USB, pero de vez en cuando había casos mucho más horribles.
      Normalmente, en estas situaciones ejecuto rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100 y expulso rápido la unidad antes de que se escriba algo más.
      Especialmente cuando hay que copiar datos desde un disco que se está deteriorando, lo último que quieres es que empiece una indexación completa y se escriba en el disco.
      En serio, esto debería tener una opción de configuración.
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      Pon esto en un script y agrégalo a crontab.

  • .DS_Store parece un diseño bastante desafortunado. Tiene un propósito y hay varias soluciones alternativas, pero en la práctica terminó siendo algo que esparce basura de archivos para el 99% de las personas que se lo encuentran
    En cuanto al acabado de la experiencia de usuario, no se siente muy propio de Apple
    Crecí usando System 7.5, OS X y Windows al mismo tiempo, y la Mac tendía a no obligarte a ver detalles de implementación como archivos o formatos de archivo innecesarios, o “cómo funciona internamente la computadora”
    Por eso se me hace raro que este archivo aparezca por todas partes: no encaja para nada con mi modelo mental de la Mac

    • Quien vive solo dentro del ecosistema de Apple nunca ve archivos .DS_Store a menos que use la terminal
      Finder ya no los muestra ni siquiera si activas la visualización de archivos ocultos
      Pero al compartir archivos desde una Mac con usuarios de Windows, se ve realmente feo, y creo que puede dar una mala primera impresión a alguien que esté considerando pasarse a Mac
    • La calidad de acabado de Apple siempre estuvo más cerca de la superficie que del interior

  • No entiendo por qué tiene que estar dentro de la misma carpeta. ¿No podría el sistema operativo tener en algún lugar su propia pequeña base de datos y referenciar cada ruta?

    • La intención era que metadatos como las etiquetas de archivos se movieran junto con la unidad de red, sin importar desde qué dispositivo se usara
    • Tenerlo dentro de la carpeta también tiene la ventaja de que, cuando se elimina la carpeta, se elimina naturalmente junto con ella

  • Estoy de acuerdo con que “solo debería crearse cuando el usuario realmente ajusta la configuración de vista o fija manualmente la posición de los íconos dentro de la carpeta”. Pero en la práctica, con solo visitar una carpeta está casi garantizado que se cree .DS_Store
    Esa es mi mayor queja con Finder
    Poder personalizar de muchas formas la apariencia y el tamaño de las ventanas de carpetas individuales, como en el Finder de Classic Mac OS, es una función realmente buena
    Pero si solo pasas por esa misma carpeta en una ventana de navegador, aunque no hayas cambiado nada, la mayor parte de esa personalización termina sobrescrita por la configuración de la ventana de navegador
    Si se va a romper tan fácilmente, no tiene sentido permitir una personalización tan buena
    Abro la carpeta Applications con un atajo global, pero no sirve de nada querer personalizar la apariencia de esa ventana. Cada vez que presiono el atajo no sé qué voy a ver, y se sigue restableciendo
    La razón es que Finder no tiene una forma de configurar una disposición predeterminada para la ventana de navegador. En cambio, deja la configuración actual del navegador en cada carpeta que visitas, y eso es realmente frustrante

    • Antes de Darwin, cada carpeta abierta correspondía a una ventana, y además había un solo usuario, así que ese enfoque funcionaba bien
      Me encantaba, y lo extraño, que la misma ventana apareciera al frente exactamente como la había dejado la última vez
    • No es global, pero dentro de Finder puedes abrir la carpeta Applications con cmd-shift-A y la carpeta Utilities con cmd-shift-U

  • Como no soy usuario de Mac, siempre me molesta un poco cuando un .tgz descargado de lugares como GitHub viene lleno de .DS_Store
    Creo que macOS probablemente usa GNU tar, y me sorprende bastante que no lo hayan modificado o configurado para ignorar .DS_Store por defecto

    • No es el valor predeterminado, pero se puede hacer que actúe así
      Si exportas COPYFILE_DISABLE=true, tar omite los archivos .DS_Store
    • La mayoría de las utilidades Unix de Mac no fueron especialmente retocadas por Apple, sino que vienen casi tal cual de FreeBSD

  • Vale la pena mencionar que hay una forma de desactivar por defecto la creación de archivos .DS_Store al explorar volúmenes de red. De lo contrario, con solo recorrerlos en Finder cambia la hora de modificación de los directorios, y eso es de lo peor
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • macOS hoy en día es quisquilloso. Cuando miré en Finder si había .DS_Store en un volumen de red, parecía que no, pero al ir a la terminal vi que en realidad sí estaba
      Ya no se puede confiar en la función de Finder para mostrar archivos ocultos. En vez de mostrar todos los archivos ocultos, solo muestra los archivos ocultos que Finder considera que al usuario le deberían importar
      Mi recurso compartido de red es un Synology local, así que no es un gran problema, pero en el trabajo estos archivos generaban situaciones bastante desordenadas
    • Personalmente, hago que los usuarios de Mac configuren esto antes de recibir permisos de escritura en recursos compartidos de red. Lo veo como una etiqueta básica de uso compartido
    • Si administras Samba, también puedes configurar Samba para que simplemente ignore esas solicitudes de creación

  • También están los archivos punto-guion bajo (._). ¿Hay alguna forma de desactivar que se creen estos archivos en recursos compartidos de red?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • Por suerte, si usas Dired, el administrador de archivos de Emacs, puedes hacer fácilmente como si no existieran estos molestos archivitos ni los archivos que genera la ejecución de LaTeX
    (setq dired-omit-mode t
    dired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")