Der Ursprung von .DS_Store (2006)

 (arno.org)
3 Punkte von GN⁺ 2024-07-04 | 1 Kommentare | Auf WhatsApp teilen
  • .DS_Store ist die Abkürzung für Desktop Services Store, entstanden beim Neubau des Finders für Mac OS X im Jahr 1999
  • Die damalige Finder-Codebasis war etwa 8 Jahre alt, sodass selbst kleine Änderungen hohe Kosten verursachten und scheinbar unabhängige Funktionen kaputtgingen, was eine vollständige Neuschreibung notwendig machte
  • Der neue Finder trennte Benutzeroberfläche und Backend; das Backend übernahm Metadaten wie Dateiauflistung, Überwachung von Änderungen, Icon-Positionen und Ordnereinstellungen
  • Das Finder-Backend wurde zu einem Kandidaten für eine öffentliche API, die auch außerhalb des Finders nutzbar sein sollte, und erhielt im Zusammenhang mit der Idee, den Finder in „Desktop“ umzubenennen, den Namen Desktop Services
  • .DS_Store sollte ursprünglich nur entstehen, wenn Anzeigeeinstellungen oder Icon-Positionen geändert wurden, wird wegen eines Bugs aber oft schon beim bloßen Besuch eines Ordners erzeugt

Die Entstehung des Namens Desktop Services Store

  • Als Apple 1999 den Finder für Mac OS X neu entwickelte, war die bestehende Finder-Codebasis bereits etwa 8 Jahre alt
    • Änderungen erforderten großen Engineering-Aufwand
    • Änderungen zerstörten meist 2 bis 3 scheinbar nicht zusammenhängende Funktionen
    • Es wurde entschieden, den Finder für Mac OS X von Grund auf neu zu schreiben
  • Im Zuge der Neuschreibung wurden die Benutzeroberfläche und das Backend der Kernfunktionen des Finders getrennt
    • Die internen Namen waren Finder_FE bzw. Finder_BE
    • Das Backend war für Dateiauflistung, Überwachung von Dateisystemänderungen, Metadatenverarbeitung, Icon-Positionen und Ordnereinstellungen zuständig
  • Das Finder-Backend konnte auch außerhalb des Finders nützlich sein, daher entstand der Plan, es eines Tages als öffentliche API bereitzustellen
    • Auf Basis früherer Erfahrungen mit den Namen Icon Services und Navigation Services wurde der Name Desktop Services gewählt
    • Damals wurde auch geprüft, den Finder in „Desktop“ umzubenennen
    • .DS_Store leitet sich von „Desktop Services Store“ ab
    • Der führende . wurde gewählt, damit die Datei auf Unix-artigen Betriebssystemen und auf dem Mac als unsichtbare Datei behandelt wird

Entstehungsbedingungen und spätere Auswirkungen

  • Der Name hätte auch beschreibender ausfallen können, ließ sich aber schwer ändern, nachdem er bereits weit verbreitet war
  • Die .DS_Store-Datei sollte ursprünglich nur erstellt werden, wenn ein Benutzer die Anzeigeeinstellungen eines Ordners anpasste oder Icon-Positionen manuell festlegte
    • Wegen eines nie behobenen Bugs wird die Datei jedoch übermäßig oft erzeugt
    • Tatsächlich ist es fast garantiert, dass schon der bloße Besuch eines Ordners eine .DS_Store-Datei erzeugt
  • Finder_BE, also Desktop Services, wird auch außerhalb des Finders verwendet
    • Navigation Services, also die Öffnen-/Speichern-Dialoge, verwendeten dies später ebenfalls
    • In frühen Releases von Mac OS nutzte Navigation Services dies noch nicht
    • Die Desktop Services API wurde bis heute nicht vollständig veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-04
Hacker-News-Kommentare

  • Neben dieser Datei gab es auch wegen des Konzepts der Forks im Mac-Dateisystem verwirrende Momente.
    Mit Fork war hier nicht fork() gemeint, sondern eine Struktur, bei der innerhalb des Dateisystems eine Datenkomponente und eine Ressourcenkomponente als Paar existierten; eine wurde eher wie Metadaten, die andere wie der Dateiinhalt behandelt.
    Unter Unix lagen Metadaten in den Directory-Block-Inodes und waren nicht in einer fest an die Datei gebundenen Form vorhanden, sodass Strukturen wie tar, cpio oder zip sie gesondert darstellen mussten.
    Wollte man unter Unix Mac-kompatible Dateiunterstützung implementieren, musste man den Resource Fork als Daten erster Klasse behandeln; die naheliegende Methode war, neben jede Datei eine Datei wie .file zu legen.
    Damals ließen sich im Inode-Block von UFS nicht alle Eigenschaften eines Resource Forks abbilden, und auch Dinge wie Icons waren darin enthalten. Modernere Dateisysteme haben größere Directory-Block-Strukturen und können solche Daten besser handhaben.

    • „Eine sind Metadaten, die andere der Dateiinhalt“ halte ich für keine genaue Beschreibung eines Resource Forks.
      Treffender ist es, von zwei Sätzen von Dateiinhalten zu sprechen: einer hieß data, der andere rsrc, und auf der Platte waren beide einfach Byte-Streams.
      Allerdings speicherte der Resource Fork üblicherweise Strukturen aus kleinen Datenstücken, die über einen 4-Byte-Typcode und eine 2-Byte-Integer-ID indiziert wurden.
      68K-Mac-Anwendungen legten fast alles im Resource Fork ab: Code, Menüs, Dialoge, Bilder, Icons, Strings usw. Kopierte man alte Mac-Apps ohne Konvertierung auf einen PC oder nach Unix, sahen sie wie leere Dateien aus.
      Deshalb musste man Mac-Apps für die Übertragung über ein Netzwerk in einen einzelnen Stream codieren; anfangs wurden BinHex .hqx oder MacBinary .bin verwendet, später Stuffit-Archive .sit.
      Der Grund, warum diese Struktur nicht zu Inodes passt, ist, dass man damit im Grunde versucht, eine ganze Datei dort hineinzuzwängen. Die Resource-Fork-Struktur selbst hatte zwar eine 16-MB-Grenze, aber wenn man sie als separaten Daten-Stream behandelte, konnte man sie beliebig groß machen.
    • Soweit ich mich erinnere, enthielten Resource Forks die Dinge, die man früher mit ResEdit bearbeitete. Icons, verschiedene GUI-Ressourcen sowie Text- und Übersetzungs-Assets waren ebenfalls möglich.
      Zum Beispiel verwendeten Escape-Velocity-Plug-ins eigene Ressourcentypen und ließen sich mit dem ResEdit-Plug-in leicht bearbeiten.
    • Auch NTFS hat Alternate Data Streams, aber ich denke, sie werden kaum genutzt.
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • Anwendungsmetadaten, etwa welche Dateiformate eine Anwendung öffnen kann oder welches Icon verwendet werden soll, wenn es zum Creator Code der Anwendung passt, wurden im Resource Fork der jeweiligen Anwendung gespeichert; Dateimetadaten wurden jedoch nicht im Resource Fork gespeichert.
      Dateityp, Creator Code, Lock-, Invisible- und Bozo-Bits usw. wurden immer im Dateisystem gespeichert.
      Siehe zum Beispiel die Beschreibung des MFS-Datenträgerformats: https://wiki.osdev.org/MFS#File_Directory_Blocks
    • Wegen der geforkten Daten war das Erstellen von Dual-Format-CDs/DVDs ziemlich interessant. Anfangs war es eine Art Trick, später erledigte Mac-Brennsoftware das recht problemlos.
      Auch das Erstellen einer Mac-Boot-DVD war durchaus nicht trivial.

  • Ich erinnere mich, dass es früher eine Möglichkeit gab, die Erstellung von .DS_Store abzuschalten, aber Apple hat sie entfernt, und ich verstehe überhaupt nicht, warum sie diese Änderung vorgenommen haben.
    Am Ende habe ich sogar selbst ein Programm geschrieben, das das gesamte Dateisystem überwacht und .DS_Store sofort löscht, sobald es entsteht.
    [0] https://github.com/slmjkdbtl/dskill

    • Auf Netzwerk-Volumes kann man es deaktivieren.
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      Ich erinnere mich nicht, dass es jemals eine Möglichkeit gab, es auf lokalen Volumes abzuschalten.
    • Apple hat es wirklich vermasselt, als sie anfingen, im Root des Dateisystems Dateien anzulegen, die mit . beginnen.
      Nachdem .DS_Store erlaubt war, scheinen andere Engineers Dinge wie .fseventsd und .Spotlight-V100 ebenfalls leicht durchgewunken zu haben.
      Ich weiß gar nicht, wie viele durch solche Dateien „verschmutzte“ Dateisysteme ich gesehen habe. Meist waren es SD-Karten oder USB-Sticks, aber gelegentlich gab es noch viel schlimmere Fälle.
      In solchen Situationen führe ich normalerweise rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100 aus und werfe das Laufwerk schnell aus, bevor noch mehr geschrieben wird.
      Besonders wenn man Daten von einer Platte kopieren muss, deren Zustand sich verschlechtert, ist das Letzte, was man will, dass eine vollständige Indexierung startet und auf die Platte geschrieben wird.
      Im Ernst: Dafür sollte es eine Einstellungsoption geben.
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      Das einfach in ein Skript packen und zu crontab hinzufügen.

  • .DS_Store wirkt wie ein wirklich unglückliches Design. Es hat einen Zweck und es gibt diverse Workarounds, aber in der Praxis ist es zu etwas geworden, das für 99 % der Menschen, die damit in Berührung kommen, Dateimüll verbreitet
    Was den Feinschliff der User Experience angeht, wirkt das untypisch für Apple
    Ich bin mit System 7.5, OS X und Windows parallel aufgewachsen, und der Mac war eher die Plattform, die einen nicht unnötig mit Implementierungsdetails wie überflüssigen Dateien, Dateiformaten oder „wie der Computer intern funktioniert“ konfrontierte
    Deshalb fühlt es sich für mich seltsam an, dass diese Datei überall auftaucht, weil es so gar nicht zu meinem mental model vom Mac passt

    • Wer ausschließlich im Apple-Ökosystem lebt, bekommt .DS_Store-Dateien nie zu sehen, solange er kein Terminal benutzt
      Der Finder zeigt sie inzwischen selbst dann nicht mehr an, wenn die Anzeige versteckter Dateien aktiviert ist
      Wenn man aber von einem Mac aus Dateien mit Windows-Nutzern teilt, sieht das wirklich unschön aus und kann Leuten, die über einen Wechsel zum Mac nachdenken, einen schlechten ersten Eindruck vermitteln
    • Apples Verarbeitungsqualität lag schon immer näher an der Oberfläche als im Inneren

  • Ich verstehe nicht, warum sie im selben Ordner liegen muss. Könnte das Betriebssystem nicht irgendwo eine eigene kleine Datenbank führen und die jeweiligen Pfade referenzieren?

    • Die Absicht war, dass Metadaten wie Datei-Labels mitwandern, egal auf welchem Gerät ein Netzlaufwerk genutzt wird
    • Im Ordner zu liegen hat außerdem den Vorteil, dass sie beim Löschen des Ordners ganz natürlich mitgelöscht wird

  • Ich stimme der Aussage zu, dass sie „nur erzeugt werden sollte, wenn der Nutzer tatsächlich die Anzeigeeinstellungen anpasst oder die Positionen der Icons in einem Ordner manuell festlegt“. In der Praxis ist es aber fast garantiert, dass schon beim bloßen Besuch eines Ordners eine .DS_Store entsteht
    Das ist mein größter Kritikpunkt am Finder
    Dass man wie im Finder von Classic Mac OS Aussehen und Größe einzelner Ordnerfenster stark anpassen kann, ist wirklich eine tolle Funktion
    Aber wenn man denselben Ordner nur in einem Browserfenster durchquert, werden die meisten dieser Anpassungen von den Einstellungen des Browserfensters überschrieben, obwohl man gar nichts geändert hat
    Wenn es so leicht kaputtgeht, hat es keinen Sinn, großartige Anpassungsmöglichkeiten zu erlauben
    Ich öffne den Applications-Ordner per globalem Kurzbefehl, aber selbst wenn ich das Aussehen dieses Fensters gestalten möchte, bringt es nichts. Bei jedem Drücken des Kurzbefehls weiß ich nicht, was ich zu sehen bekomme, und es wird immer wieder zurückgesetzt
    Der Grund ist, dass es im Finder keine Möglichkeit gibt, eine Standardkonfiguration für Browserfenster festzulegen. Stattdessen hinterlässt er in jedem besuchten Ordner die aktuellen Browsereinstellungen, was wirklich frustrierend ist

    • Vor Darwin entsprach ein geöffneter Ordner einem Fenster, und es gab nur einen Nutzer, daher passte dieser Ansatz gut
      Es war wirklich schön, dass dasselbe Fenster genau so wieder nach vorne kam, wie man es zuletzt hinterlassen hatte; das vermisse ich
    • Nicht systemweit, aber innerhalb des Finders kann man mit cmd-shift-A den Applications-Ordner öffnen und mit cmd-shift-U den Utilities-Ordner

  • Da ich kein Mac-Nutzer bin, nervt es mich immer etwas, wenn in einem .tgz von GitHub oder ähnlichen Orten jede Menge .DS_Store steckt
    macOS verwendet vermutlich GNU tar, aber es überrascht mich ziemlich, dass es nicht so angepasst oder konfiguriert wurde, dass .DS_Store standardmäßig ignoriert wird

    • Standardmäßig ist das nicht so, aber man kann es dazu bringen
      Wenn man COPYFILE_DISABLE=true exportiert, überspringt tar die .DS_Store-Dateien
    • Die meisten Unix-Utilities auf dem Mac wurden von Apple nicht besonders angepasst, sondern stammen nahezu unverändert aus FreeBSD

  • Es ist erwähnenswert, dass man die Erstellung von .DS_Store-Dateien beim Durchsuchen von Netzwerk-Volumes standardmäßig deaktivieren kann. Sonst ändert sich schon beim bloßen Herumstöbern mit dem Finder die Änderungszeit von Verzeichnissen, und das ist wirklich übel
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • Das heutige macOS ist heikel. Als ich im Finder nachgesehen habe, ob auf einem Netzwerk-Volume eine .DS_Store liegt, schien keine da zu sein, aber im Terminal war sie tatsächlich vorhanden
      Auf die Funktion des Finders zum Anzeigen versteckter Dateien kann man sich inzwischen nicht mehr verlassen. Statt alle versteckten Dateien zu zeigen, zeigt er nur die versteckten Dateien an, von denen der Finder meint, dass Nutzer sich darum kümmern sollten
      Meine Netzwerkfreigabe ist eine lokale Synology, daher ist es kein großes Problem, aber im Job haben solche Dateien für ziemlich unordentliche Zustände gesorgt
    • Persönlich lasse ich Mac-Nutzer diese Einstellung vornehmen, bevor sie Schreibrechte auf Netzwerkfreigaben bekommen. Ich halte das für vernünftige Etikette bei gemeinsamer Nutzung
    • Wenn man Samba betreibt, kann man auch die Samba-Konfiguration so einstellen, dass solche Erstellungsanfragen einfach ignoriert werden

  • Es gibt auch Punkt-Unterstrich-Dateien (._). Gibt es eine Möglichkeit, zu deaktivieren, dass solche Dateien auf Netzwerkfreigaben entstehen?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • Zum Glück kann man mit dem Emacs-Dateimanager Dired diese lästigen kleinen Dateien und die von LaTeX-Läufen erzeugten Dateien leicht so tun, als gäbe es sie nicht
    (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\\)$")