Les origines de .DS_Store (2006)

 (arno.org)
3 points par GN⁺ 2024-07-04 | 1 commentaires | Partager sur WhatsApp
  • .DS_Store est l’abréviation de Desktop Services Store, née lors de la réécriture du Finder pour Mac OS X en 1999
  • À l’époque, la base de code du Finder avait environ 8 ans : même de petits changements coûtaient cher et cassaient des fonctionnalités apparemment sans rapport, ce qui a rendu nécessaire une réécriture complète
  • Le nouveau Finder séparait l’interface utilisateur du backend ; celui-ci gérait l’énumération des fichiers, la surveillance des changements, ainsi que les métadonnées comme la position des icônes et les réglages des dossiers
  • Le backend du Finder est devenu un candidat à une API publique utilisable en dehors du Finder et, dans le contexte d’une possible renommage du Finder en « Desktop », a reçu le nom Desktop Services
  • À l’origine, .DS_Store ne devait être créé que lors de la modification des paramètres d’affichage ou de la position des icônes, mais à cause d’un bug il est souvent généré dès qu’un dossier est simplement visité

La naissance du nom Desktop Services Store

  • En 1999, au moment où Apple reconstruisait le Finder pour Mac OS X, la base de code existante du Finder avait environ 8 ans
    • Les modifications demandaient un important effort d’ingénierie
    • Une modification cassait généralement 2 ou 3 fonctionnalités qui semblaient sans rapport
    • Il a été décidé de réécrire le Finder pour Mac OS X depuis zéro
  • Lors de cette réécriture, l’interface utilisateur du Finder et le backend de ses fonctions essentielles ont été séparés
    • Leurs noms internes étaient respectivement Finder_FE et Finder_BE
    • Le backend était chargé de l’énumération des fichiers, de la surveillance des changements du système de fichiers, du traitement des métadonnées, de la position des icônes et des réglages des dossiers
  • Comme le backend du Finder pouvait aussi être utile en dehors du Finder, l’idée est née d’en faire un jour une API publique
    • En s’appuyant sur l’expérience des noms Icon Services et Navigation Services, le nom Desktop Services a été choisi
    • À l’époque, l’idée de renommer le Finder en « Desktop » était également à l’étude
    • .DS_Store vient du nom « Desktop Services Store »
    • Le . initial a été choisi pour que le fichier soit traité comme invisible sur les systèmes de type Unix et sur Mac OS

Conditions de création et impact ultérieur

  • Le nom aurait pu être plus descriptif, mais une fois largement utilisé, il est devenu difficile à changer
  • Le fichier .DS_Store ne devait à l’origine être créé que lorsque l’utilisateur ajustait les réglages d’affichage d’un dossier ou positionnait manuellement des icônes
    • Cependant, un bug non corrigé a entraîné une création excessive de ces fichiers
    • En pratique, le simple fait de visiter un dossier garantit presque la création d’un fichier .DS_Store
  • Finder_BE, c’est-à-dire Desktop Services, est aussi utilisé en dehors du Finder
    • Navigation Services, c’est-à-dire les boîtes de dialogue d’ouverture/enregistrement, a fini par l’utiliser également
    • Dans les premières versions de Mac OS, Navigation Services ne l’utilisait pas
    • L’API Desktop Services n’est pas encore entièrement publique

À lire aussi

1 commentaires

 
GN⁺ 2024-07-04
Avis sur Hacker News

  • Au-delà de ce fichier, le concept de fork dans le système de fichiers Mac a aussi été une source de confusion
    Ici, fork ne désignait pas fork(), mais une structure où les composants de données et de ressources existaient par paire dans le système de fichiers ; l’un était traité comme des métadonnées, l’autre comme le contenu du fichier
    Sous Unix, les métadonnées se trouvaient du côté des inode des blocs de répertoire et n’étaient pas liées de façon unique au fichier, donc des formats comme tar, cpio ou zip devaient les représenter séparément
    Pour implémenter la prise en charge de fichiers compatibles Mac sous Unix, il fallait traiter le resource fork comme une donnée de première classe, et la manière la plus naturelle consistait à placer un fichier du type .file à côté de chaque fichier
    À l’époque, les blocs inode d’UFS ne permettaient pas de mapper toutes les propriétés du resource fork, qui pouvait aussi contenir des éléments comme des icônes. Les systèmes de fichiers plus modernes ont des structures de blocs de répertoire plus vastes et peuvent mieux gérer ce type de données

    • Dire que « l’un est une métadonnée et l’autre le contenu du fichier » n’est pas une description très exacte du resource fork
      Il est plus juste de considérer qu’il y avait deux ensembles de contenu de fichier : l’un appelé data, l’autre rsrc, et sur le disque les deux n’étaient au fond que des flux d’octets
      Cela dit, le resource fork stockait généralement une structure de petits fragments de données indexés par un code de type sur 4 octets et un identifiant entier sur 2 octets
      Les applications Mac 68K plaçaient presque tout dans le resource fork : code, menus, boîtes de dialogue, images, icônes, chaînes de caractères, etc., si bien que copier une ancienne application Mac sur PC ou Unix sans conversion la faisait apparaître comme un fichier vide
      C’est pourquoi, pour envoyer une application Mac sur le réseau, il fallait l’encoder sous forme d’un flux unique ; au début on utilisait BinHex .hqx ou MacBinary .bin, puis plus tard les archives Stuffit .sit
      Si cela ne rentrait pas dans un inode, c’est essentiellement parce qu’on essayait d’y faire tenir un fichier entier. La structure du resource fork elle-même avait une limite de 16 Mo, mais si on le traitait comme un flux de données séparé, on pouvait le rendre aussi gros qu’on le voulait
    • Il me semble que le resource fork contenait autrefois les choses qu’on éditait avec ResEdit : icônes, diverses ressources GUI, ainsi que du texte et des ressources de traduction
      Par exemple, les plugins d’Escape Velocity utilisaient des types de ressources personnalisés, qu’on pouvait facilement modifier avec un plugin ResEdit
    • NTFS a lui aussi des flux de données alternatifs (Alternate Data Streams), mais ils sont à mon avis très peu utilisés
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • Les métadonnées applicatives, comme les formats de fichier qu’une application peut ouvrir ou l’icône à utiliser lorsqu’un fichier correspond au creator code de l’application, étaient stockées dans le resource fork de cette application, mais les métadonnées du fichier lui-même ne l’étaient pas
      Le type de fichier, le creator code, les attributs lock, invisible, le bit bozo, etc., ont toujours été stockés dans le système de fichiers
      On peut par exemple regarder la description du format de disque MFS : https://wiki.osdev.org/MFS#File_Directory_Blocks
    • À cause des données forkées, créer des CD/DVD à double format était assez intéressant. Au début c’était une sorte de bidouille, mais plus tard les logiciels de gravure Mac ont facilité la chose
      Créer un DVD de démarrage Mac n’était pas non plus une mince affaire

  • Il me semble qu’autrefois il existait un moyen de désactiver la création de .DS_Store, mais Apple l’a supprimé, et je ne comprends absolument pas pourquoi ils ont fait ce changement
    J’ai fini par écrire moi-même un programme qui surveillait tout le système de fichiers et supprimait .DS_Store dès son apparition
    [0] https://github.com/slmjkdbtl/dskill

    • On peut le désactiver sur les volumes réseau
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      Je ne me souviens pas qu’il ait déjà existé un moyen de le désactiver sur les volumes locaux
    • Apple a vraiment mis le bazar en commençant à créer des fichiers commençant par . à la racine du système de fichiers
      Une fois .DS_Store accepté, on a l’impression que d’autres ingénieurs ont pu faire approuver sans difficulté des choses comme .fseventsd ou .Spotlight-V100
      Je ne compte plus le nombre de systèmes de fichiers « pollués » que j’ai vus à cause de ça. C’étaient surtout des cartes SD ou des clés USB, mais parfois c’était bien pire
      En général, dans ce genre de situation, je lance rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100, puis j’éjecte rapidement le disque avant que quoi que ce soit d’autre n’y écrive
      Surtout quand il faut copier des données depuis un disque en mauvais état, la dernière chose qu’on veut, c’est qu’un indexage complet démarre et écrive sur le disque
      Sérieusement, ce genre de chose devrait avoir une option de configuration
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      Il suffit de mettre ça dans un script et de l’ajouter à crontab

  • .DS_Store donne vraiment l’impression d’une conception malheureuse. Il y a bien une intention derrière et plusieurs contournements existent, mais dans les faits, c’est devenu quelque chose qui répand des fichiers poubelles chez 99 % des personnes qui y sont confrontées
    En matière de finition de l’expérience utilisateur, ce n’est pas très Apple
    J’ai grandi en utilisant à la fois System 7.5, OS X et Windows, et le Mac était justement la plateforme qui évitait de vous exposer inutilement des détails d’implémentation comme des fichiers superflus, des formats de fichiers ou « la manière dont l’ordinateur fonctionne en interne »
    Du coup, voir ce fichier apparaître partout cadre tellement mal avec mon modèle mental du Mac que ça me semble étrange

    • Les gens qui vivent uniquement dans l’écosystème Apple ne verront jamais les fichiers .DS_Store, à moins d’utiliser le terminal
      Même Finder ne les affiche plus désormais, même si l’on active l’affichage des fichiers cachés
      En revanche, quand on partage des fichiers depuis un Mac avec des utilisateurs Windows, c’est vraiment disgracieux, et je pense que cela peut donner une mauvaise première impression à quelqu’un qui envisage de passer au Mac
    • La qualité de finition d’Apple a toujours été plus proche de la surface que de l’intérieur

  • Je ne comprends pas pourquoi cela doit se trouver dans le même dossier. Le système d’exploitation ne pourrait-il pas garder sa propre petite base de données quelque part et référencer chaque chemin ?

    • L’idée était que des métadonnées comme les étiquettes de fichiers puissent suivre le lecteur réseau et rester avec lui, quel que soit l’appareil depuis lequel on l’utilise
    • Le fait de les mettre dans le dossier a aussi l’avantage qu’elles soient supprimées naturellement quand le dossier l’est

  • Je suis d’accord avec l’idée que « cela ne devrait être créé que lorsque l’utilisateur ajuste réellement les réglages d’affichage ou place manuellement les icônes dans le dossier ». Mais en pratique, il est quasiment garanti qu’un .DS_Store sera créé rien qu’en visitant un dossier
    C’est de loin ce qui m’agace le plus dans Finder
    Le fait de pouvoir personnaliser de manière très variée l’apparence et la taille des fenêtres de dossiers individuels, comme dans le Finder du Classic Mac OS, est une fonctionnalité vraiment excellente
    Mais il suffit souvent de parcourir ce même dossier dans une fenêtre de navigation pour que, sans rien modifier, la plupart de ces personnalisations soient écrasées par les réglages de cette fenêtre de navigation
    Si cela se casse aussi facilement, cela n’a aucun sens de permettre une personnalisation aussi poussée
    J’ouvre le dossier Applications avec un raccourci global, mais même si je veux soigner l’apparence de cette fenêtre, cela ne sert à rien. Impossible de savoir ce que je vais voir quand j’appuie sur le raccourci, et tout est sans cesse réinitialisé
    La raison, c’est qu’il n’existe aucun moyen de définir une configuration par défaut pour la fenêtre de navigation dans Finder. À la place, il enregistre les réglages actuels du navigateur dans chaque dossier visité, ce qui est vraiment frustrant

    • Avant Darwin, chaque dossier ouvert correspondait à une fenêtre et il n’y avait qu’un seul utilisateur, donc cette approche était bien adaptée
      C’était vraiment agréable, et cela me manque, de voir réapparaître au premier plan la même fenêtre exactement dans l’état où on l’avait laissée
    • Ce n’est pas global, mais dans Finder on peut ouvrir le dossier Applications avec cmd-shift-A, et le dossier Utilities avec cmd-shift-U

  • Je ne suis pas utilisateur Mac, donc quand je télécharge une .tgz depuis GitHub ou ailleurs et qu’elle est pleine de .DS_Store, ça m’agace toujours un peu
    macOS semble probablement utiliser GNU tar, donc c’est assez surprenant qu’ils ne l’aient ni modifié ni configuré pour ignorer .DS_Store par défaut

    • Ce n’est pas le comportement par défaut, mais on peut le configurer ainsi
      Si on exporte COPYFILE_DISABLE=true, tar ignore les fichiers .DS_Store
    • La plupart des utilitaires Unix du Mac ne sont pas des outils spécialement retouchés par Apple, ils viennent presque tels quels de FreeBSD

  • Cela vaut la peine de mentionner qu’il existe un moyen de désactiver par défaut la création de fichiers .DS_Store lors de la navigation sur des volumes réseau. Sinon, le simple fait de parcourir les répertoires avec Finder modifie leur horodatage de modification, ce qui est vraiment le pire
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • Les versions récentes de macOS sont pénibles. Quand j’ai regardé dans Finder si des .DS_Store existaient sur un volume réseau, il semblait ne pas y en avoir, mais en passant par le terminal, ils étaient bien là
      On ne peut plus faire confiance à la fonction d’affichage des fichiers cachés de Finder. Au lieu de tout montrer, elle n’affiche plus que les fichiers cachés que Finder estime pertinents pour l’utilisateur
      Mon partage réseau est un Synology local, donc ce n’est pas bien grave, mais au travail, ces fichiers ont créé des situations assez sales
    • Personnellement, je fais appliquer ce réglage aux utilisateurs Mac avant de leur donner les droits d’écriture sur un partage réseau. Pour moi, c’est simplement une question de savoir-vivre en usage partagé
    • Si vous administrez Samba, vous pouvez aussi régler la configuration de Samba pour simplement ignorer ces demandes de création

  • Il y a aussi les fichiers point-souligné (._). Existe-t-il un moyen de désactiver leur création sur les partages réseau ?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • Heureusement, si l’on utilise Dired, le gestionnaire de fichiers d’Emacs, il est facile de faire comme si ces petits fichiers pénibles — ainsi que ceux générés par les exécutions de LaTeX — n’existaient pas
    (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\\)$")