Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

DS_Store: Was sind das für Dateien auf dem Mac?

Der Finder merkt sich, welche Einstellungen Nutzer für Ordner getroffen haben – beispielsweise die Icon-Positionen und ob ein Ordner in Listendarstellung oder im Icon-Modus geöffnet werden soll. Um diese Informationen zu speichern, verwendet Apple versteckte Dateien, welche der Finder nicht anzeigt. Doch wenn man das Terminal öffnet, sieht man in fast allen Ordnern so genannte ".DS_Store"-Dateien. Der Punkt signalisiert, dass es sich hierbei um versteckte Dateien handelt.

".DS_Store" steht für "Desktop Services Stores" – und wie schon oben erwähnt nutzt Apple diese Dateien, um Informationen über den Inhalt von Ordnern zu speichern. Neben den Darstellungsoptionen sichert Apple hier auch Kommentare zu einzelnen Dateien, welche über das Informations-Fenster im Finder verfasst wurden.

Keine Anzeige im Finder möglich
Der Finder bietet in den Einstellungen die Möglichkeit, auch versteckte Dateien einzublenden, welche mit einem Punkt beginnen. Doch lässt der Finder hier ".DS-Store"-Dateien außen vor und blendet nur andere, versteckte Dateien ein. Kurzer Tipp: Wenn man schnell "Hidden Files" im Finder einblenden will, genügt die Tastenkombination ++Punkt, um die Option ein- und auszuschalten.

Probleme bei Versionsverwaltung und Terminal-Scripten
Doch obwohl der Finder die Dateien nicht anzeigt, handelt es sich dennoch um normale Dateien, welche von Versionskontrollsystemen wie beispielswiese GIT oder Terminal-Skripten verarbeitet werden. Dadurch entstehen schnell Probleme: Landen diese ".DS_Store"-Dateien in GIT-Archiven, kommt es schnell zu Konflikten: Hat ein Nutzer die Finder-Darstellung geändert, behandelt die Versionsverwaltung GIT diese wie eine normale Änderung – und es entsteht im GIT-Archiv ein Konflikt wegen gleichzeitiger Änderungen. Glücklicherweise lässt sich GIT über eine Ignore-Liste abgewöhnen, diese Dateien überhaupt zu erfassen. Doch sonstige Terminal-Skripte, welche mit der Existenz solcher Dateien nicht rechnen, können schnell Probleme mit den versteckten Dateien bekommen.

".DS_Store"-Dateien entfernen
Will man ".DS_Store"-Dateien aus einem bestimmten Ordner rekursiv (also samt Unterordner) entfernen, reicht ein einfacher Terminal-Befehl, welchen man im Zielordner ausführt:

find . -name ".DS_Store" -delete

Doch leider erzeugt der Finder und Spotlight diese Dateien erneut, sobald der Nutzer den entsprechenden Ordner erneut im Finder öffnet. Aktuell bietet Apple keine Möglichkeit, das Erstellen von ".DS_Store"-Dateien komplett zu deaktivieren.

Auf Netzwerk-Volumes abschalten
Wenn man oftmals mit Netzwerkfreigaben in heterogenen Netzwerken arbeitet, werden auch hier ".DS_Store"-Dateien zum Problem: Windows-Nutzer sehen diese versteckten Dateien, welche der Finder angelegt hat. Doch zumindest für diesen Problemfall hat Apple eine Lösung parat. Mit diesem Kommando im Terminal lässt sich abschalten, dass der Finder ".DS_Store"-Dateien auf Netzwerk-Volumes überhaupt anlegt oder ausliest:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Nach der Eingabe ist entweder ein Neustart des Macs erforderlich – oder ein Ab- und erneutes Anmelden. Diese Einstellung bezieht sich nur auf den aktuell angemeldeten Benutzer. Wenn man mehrere Nutzer auf dem Mac verwendet, ist das Ausführen des obigen Kommandos für alle Nutzer notwendig.

In Zukunft als APFS-Metadaten?
Die Tage der ".DS_Store"-Dateien dürften aber gezählt sein: Es ist zu erwarten, dass Apple in einem kommenden größeren macOS-Update nicht mehr versteckte Dateien für das Sichern dieser Informationen verwendet, sondern die Nutzereinstellungen als erweiterte Ordner- und Dateiattribute in APFS ablegt. Natürlich ist noch nicht bekannt, wann Apple eine solche Änderung plant – doch könnte Apple hier Pro-Nutzern mühevolle Arbeit ersparen.

Vor 30 Jahren: Apple holt Sanierer – kann das s...

Vor 15 Jahren: Als der iMac riesig wurde

Kopplung "iPhone + Apple Watch" sowie Anbindung...

iPhone 16 Pro in Einzelteilen – Details zum Auf...

Neues iPad mini

iOS 18 und iPadOS 18 lassen sich ab sofort laden

Apple Event

macOS 15 Sequoia ist da – Apple hat den Startsc...

Kommentare

MikeMuc03.12.21 09:11

Mein Tellerrand ist zu hoch. Mir sind noch nie Scripte begegnet, die sich an solchen Dateien Verschluckt oder gestöhnt gefühlt haben. Ich bin aber auch nur Gelegeheitsnutzer vom Terminal…
Die Gitgeschichte sehe ich daher „an den Haaren herbei gezogen“.
Welchen konkreten Anlass hat der Artikel und wo stören die Dateien konkret (außer beim Datenaustausch mit Windowsusern)? Hat jemand weitere Anwendungsfälle aus dem echten Leben?

-15

massi03.12.21 09:16

Für die, die nicht so gerne das Terminal quälen gibt es im Appstore "Cleanmydrive", das beim Auswerfen von externen oder Netzwerkdatenträgern .DS_Store und noch einige andere entfernt.

Mendel Kucharzeck03.12.21 09:16

Es gibt wirklich sehr viele Fälle, in denen die Probleme machen. Zum Beispiel kopierte ich Dateien vom Mac mittels rsync auf einen Testserver – rate mal, was danach auf dem Server rumplunderte?

EOTT03.12.21 09:31

Und wo genau ist jetzt das Problem?
Erster Treffer bei Google:

-2

Mendel Kucharzeck03.12.21 09:33

EOTT
Wenn man dran denkt, ist es natürlich kein Problem!

Phileas03.12.21 09:34

Wieder was gelernt. Danke.

Thomster03.12.21 09:46

Blue Harvest

nuffsed

macuser2203.12.21 09:48

Ein nerviges „Problem“ auf Netzwerk-Volumes ist meiner Meinung nach die Tatsache, dass jeder Nutzer, der ein Verzeichnis öffnet und die Darstellung ändert, das damit in diesen Dateien festhält. Stellt ein anderer Nutzer andere Ansichtsoptionen ein (also z.B. Spalten- statt Listenansicht, Fenstergröße, …) geht’s immer hin und her.

Das komplette Deaktivieren der .DS_Store Dateien dürfte diesen Umstand nicht beheben. Ich hoffe ebenfalls, dass in Zukunft die Eigenschaften eines Ordners für alle User gespeichert werden, sodass jeder seine eigenen, bevorzugten Optionen verwenden kann.

Erkenne dich selbst –//– Nichts im Übermaß

MetallSnake03.12.21 09:50

MikeMuc

Die Gitgeschichte sehe ich daher „an den Haaren herbei gezogen“.

Wieso das? So ziemlich jedes Entwickler der eine Versionsverwaltung wie svn oder git nutzt hat schon mal darüber geflucht.

MikeMuc

Welchen konkreten Anlass hat der Artikel

Das dürfte der Blog Eintrag hier gewesen sein: https://eclecticlight.co/2021/11/27/explainer-ds_store-files/

MikeMuc

und wo stören die Dateien konkret (außer beim Datenaustausch mit Windowsusern)? Hat jemand weitere Anwendungsfälle aus dem echten Leben?

Versionsverwaltung, wurde doch schon genannt. Wieso ist das kein "echtes" Leben?

Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.

Thomster03.12.21 10:03

MikeMuc

... wo stören die Dateien konkret (außer beim Datenaustausch mit Windowsusern)? Hat jemand weitere Anwendungsfälle aus dem echten Leben?

USB-Sticks für Car-Audio Systeme erstellen. In der Regel FAT-formatiert kopiert macOS zu jedem .mp3/mp4/.whatever File entsprechend auch die .irgendwas.suffix Datei ins entsprechende Verzeichnis. Da solche Geräte oft primär mal den Suffix lesen (Aha! Ein mp3 File!), interpretieren sie den Dateityp der .irgendwas.suffix falsch und wollen sie als Audiodatei lesen.

Eiertanz03.12.21 10:05

Ein weiteres Beispiel wo es Probleme mit versteckten Mac-Dateien gibt ist das VW Navi Update. VW empfiehlt deswegen auch Clean My Drive. https://www.autoradio-info.de/vw-navi-update/

ruphi03.12.21 10:06

macuser22

Würde das aber dann nicht das Problem erzeugen, dass die Options-Daten zumindest theoretisch unbegrenzt anwachsen können? Wenn ein Verzeichnis mitsamt Unterverzeichnissen z.B. für mehrere Zehntausend Nutzer freigegeben ist..

maybeapreacher03.12.21 10:28

Neben den technischen Problemen sehe ich auch den "Ruf" von Apple Nutzern bzw. Entwicklern.

Schon oft persönlich begegnet: "Oh, da kommt ein Mac User. Aber pass auf dass Du uns nicht die Daten verhunzt." Schlicht weil diese Leute (Linux und Windows User) schon oft damit gekämpft haben dass ein Mac User vorbei kam und ihnen .DS_Store Files aufs Laufwerk gelegt hat.

Marcel Bresink03.12.21 10:30

Thomster

USB-Sticks für Car-Audio Systeme erstellen. In der Regel FAT-formatiert kopiert macOS zu jedem .mp3/mp4/.whatever File entsprechend auch die .irgendwas.suffix Datei ins entsprechende Verzeichnis.

Dieses Problem ist so ähnlich, hat aber mit diesem Thread eigentlich nichts zu tun. Du meinst AppleDouble-Dateien, die macOS verwendet, um Erweiterte Attribute in alten Dateisystemen zu speichern, die das nicht von Hause aus könnnen.

In diesem Thread geht es um Desktop-Services-Store-Dateien, die der Finder verwendet, um Ansichtseinstellungen für Ordner zu speichern.

ruphi

Würde das aber dann nicht das Problem erzeugen, dass die Options-Daten zumindest theoretisch unbegrenzt anwachsen können?

Die korrekte Lösung wäre ja, die Ansichtseinstellungen für einen Ordner in den Einstellungen des "ansehenden Benutzers" zu speichern und eben nicht im Ordner (auch nicht in den Metadaten wie es der Artikel vorschlägt). Das wären dann nur wenige Daten bei jedem Benutzer. Diese Daten könnten auch automatisch bereinigt werden, wenn ein Benutzer einen Ordner soundsoviel Jahre nicht mehr geöffnet hat.

Peter Eckel03.12.21 10:35

MikeMuc

Mein Tellerrand ist zu hoch.

Du sagst es. Wie kommst Du darauf, daß ein Artikel an den Haaren herbeigezogen ist, nur weil er Dich als selbsterklärten "Terminal-Gelegenheitsnutzer" nicht betrifft? Das Problem ist real und nervt.

Ich kann zwar aus meiner Praxis nicht bestätigen, daß die Dateien Probleme ausgerechnet bei git machen - zumindest die Implementierung in Homebrew ignoriert die .DS_Store-Dateien - aber bei tar, rsync etc. stören sie schon sehr, vor allem, weil man hinterher unter Unix und Linux (von Windows weiß ich nichts, das benutze ich nie) die blöden Dinger wegräumen oder - schlimmer - seinen Kunden erklären muß, woher sie kommen und wie sie sie wegräumen können.

Als GUI-Nutzer ohne nennenswerte Exposition zum furchterregenden Terminal und fremdem System-Teufelswerk kannst Du Dich entspannt zurücklehnen und Dich freuen, daß wenigstens dieses Problem an Dir vorbeigeht.

Ceterum censeo librum facierum esse delendum.

chill03.12.21 10:38

Ich habe etliches an GB Daten, von denen ich nicht weiss was die sollen. Wären die alle weg, hätte ich deutlich mehr als 7 GB Platz (Macht schon etwas aus, bei einem 256 Gb Rechner)

Jeweils rechts die Daten: db, vm, dyld, assets, und die frameworks ...
Nein, ich habe da nicht einfach etwas gelöscht.

MBP M1 256/16 Monterey 12.1 . iPhone 11 128 GB, iOs 15.2

-9

Peter Eckel03.12.21 10:39

maybeapreacher

Schon oft persönlich begegnet: "Oh, da kommt ein Mac User. Aber pass auf dass Du uns nicht die Daten verhunzt." Schlicht weil diese Leute (Linux und Windows User) schon oft damit gekämpft haben dass ein Mac User vorbei kam und ihnen .DS_Store Files aufs Laufwerk gelegt hat.

Gerade Windows-Nutzer mit ihren üblicherweise verhunzten Zeilenenden in Textdateien (CRLF) sollten da aber lieber ganz still sein. Was ich schon mit von denen editierten Dateien für einen Ärger hatte, geht auf keine Kuhhaut, dagegen ist .DS_Store Pipifax.

Aber ja, prinzipiell würde ich stark befürworten, daß Apple auf das Anlegen dieser Krücke verzichtet. Ich weiß nur nicht woher die im Artikel geäußerte Hoffnung kommt, dies könne nun bald passieren - darauf warte ich seit Jahren

Ceterum censeo librum facierum esse delendum.

+10

Peter Eckel03.12.21 10:40

chill

Ich habe etliches an GB Daten, von denen ich nicht weiss was die sollen. Wären die alle weg, hätte ich deutlich mehr als 7 GB Platz (Macht schon etwas aus, bei einem 256 Gb Rechner)

Und das hat was genau mit dem Thema zu tun? Nichts. Gehen Sie weiter, es gibt nichts zu sehen.

Ceterum censeo librum facierum esse delendum.

frankh03.12.21 10:48

chill

Ich habe etliches an GB Daten, von denen ich nicht weiss was die sollen.

Dann mach Dich halt mal schlau...
Hat mit dem Artikel hier NICHTS zu tun...

maybeapreacher03.12.21 11:01

Peter Eckel

Zwar stimme ich Dir zu, aber die Mehrheit der Windows User kennts nunmal nicht anders "und untereinander funktionierts ja". Also sehen sie den Mac als Störfaktor. Ist ja immer Wahrnehmungssache und sowas hat ganz oft mit "gefühlten Wahrheiten" zu tun. Was bin ich schon angegangen worden von Leuten sobald sie nur den Apfel auf dem Display gesehen haben...

marm03.12.21 11:03

Eine Übersicht, was es da so alles an "." und "._" Files gibt und was sie bedeuten, wäre nützlich. Ich habe da keine Übersicht. Ich kann da nur mal anfangen:
.metadata_never_index kein Spotlight Index
.Trashes kein Papierkorb
.fseventsd irgendwas mit Logging
.Spotlight-V100 Spotlight Index
._ obskurer Kleinkram

Peter Eckel03.12.21 11:21

maybeapreacher

Ich verstehe Dein Problem - da wiederum befinde ich mich in der durchaus luxuriösen Situation, daß in "meiner Welt" die Windows-User die Exoten mit den nervigen Ideosynkrasien darstellen.

Im Grunde fallen die Probleme aber fast in die gleiche Kategorie - Apple-Systeme erzeugen lustige für sie unsichtbare Dateien auf fremden Filesystemen, Windows-Systeme haben von allen anderen abweichende Zeilenenden und verwenden ein Zeichen, das alle anderen als Escape-Zeichen benutzen, als normalen Dateipfad-Separator (auch ein Quell steter Freude). Das sollte heutzutage eigentlich alles nicht mehr passieren.

Ceterum censeo librum facierum esse delendum.

MetallSnake03.12.21 11:25

Peter Eckel

Gerade Windows-Nutzer mit ihren üblicherweise verhunzten Zeilenenden in Textdateien (CRLF) sollten da aber lieber ganz still sein.

Das und die thumbs.db Dateien, das .DS_Store der Windowsuser! 😡

Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.

MikeMuc03.12.21 11:30

Peter Eckel

Als GUI-Nutzer ohne nennenswerte Exposition zum furchterregenden Terminal und fremdem System-Teufelswerk kannst Du Dich entspannt zurücklehnen und Dich freuen, daß wenigstens dieses Problem an Dir vorbeigeht.

Lieber Peter, das ist eine Unterstellung. Furcht vor Terminal habe ich, wenn du meinen Text richtig lesen würdest, keinesfalls. Und vor fremden Systemen auch nicht. Die zerlege ich mit Freude. Aber ich habe schon oft über Scripts aus dem Internet geflucht, bei denen Pfade nicht anständig behandelt werden und die nicht mit Leerzeichen umgehen können. Ich verbuche sowas dann unter Ignoranz der Scriptschreiber die ihren Kram nur so schreiben, das er grad mal eben so für den eigenen Gebrauch läuft

Peter Eckel

oder - schlimmer - seinen Kunden erklären muß, woher sie kommen und wie sie sie wegräumen können.

Dann habe ich entweder nicht gründlich gearbeitet oder habe kein Problem damit, dem Kunden das Problem zu erklären auf das er beim nächsten Mal ein Tool hat, mit dem er entweder einfach aufräumen kann oder dafür Sorge tragen kann, das diese Dateien gar nicht erst ma Ziel aufschlagen.
Aber es fühlen sich hier anscheinend viele auf den Schlips getreten

Für die meisten hier aufgezählten Anwendungsfälle ist es doch so, das man sich, wenn man sich mit der Materie auskennt, da entsprechende "Vorsichtsmaßnahmen" ergreifen kann. Wer regelmäßig Musik auf den Stick fürs Auto kopiert, der sollte sich eine Tool besorgen oder erstellen, das die Dateien so kopiert, das keine unbrauchbaren Daten auf dem Ziel landen.

Wenn man ein Git oder ähnliches System verwendet und es läßt sich nicht "richtig" konfigurieren, dann hat ma wohl das falsche für die eigene Platform erwischt...

Für rsync wurde ja bereits eine Lösung beschrieben, wer die nicht nutzt, muß sich eben an die eigene Nase fassen wenn er hinterher Dateien hat, die er am Ziel nicht will ;

Ansonsten haben wohl die meisten System so ihre eigene "Pest". Da werden wir mit Leben müssen und jeweils einen Workaround um die spezifischen "Problemchen" anwenden müssen

-8

Peter Eckel03.12.21 12:03

MikeMuc

Peter Eckel

Lieber Peter, das ist eine Unterstellung.

Deine eigenen Worte:

MikeMuc

Ich bin aber auch nur Gelegeheitsnutzer vom Terminal…

OK, der Passus mit dem "furchterregenden Terminal" und so weiter war natürlich polemisch und nicht unbedingt auf Dich beziehbar. Keine Frage, ich wollte Dir da auch nicht auf den Schlips treten. Aber als "Gelegenheitsnutzer" siehst Du das Problem halt nur ... gelegentlich.

MikeMuc

Aber ich habe schon oft über Scripts aus dem Internet geflucht, bei denen Pfade nicht anständig behandelt werden und die nicht mit Leerzeichen umgehen können. Ich verbuche sowas dann unter Ignoranz der Scriptschreiber die ihren Kram nur so schreiben, das er grad mal eben so für den eigenen Gebrauch läuft

Nachvollziehbar. Andererseits hilft dagegen das gleiche wie gegen irgendwelche unerwünschten Effekte von "Scripts aus dem Internet": Lieber selbst schreiben.

MikeMuc

Dann habe ich entweder nicht gründlich gearbeitet oder habe kein Problem damit, dem Kunden das Problem zu erklären ...

Absolut richtig. Aber allein der Umstand, daß man sich ständig um solche Systemmacken kümmern muß (die eigentlich ziemlich unnötig sind) ist halt Grund genug, die Notwendigkeit und Sinnhaftigkeit dieser Konstruktionen zumindest mal zu hinterfragen.

Wie gesagt: Die nativen Tools auf dem Mac kümmern sich in vielen Fällen schon um die Problematik, aber allein schon, wenn man ein rsync nicht vom Mac, sondern von einem anderen System aus startet, hat man das Problem schon.

Und ja, bei den meisten Tools kann man mit entsprechenden Optionen verhindern, daß das passiert. Aber es ist nervig, bei jeder Gelegenheit auf alle denkbaren Ausnahmezustände Rücksicht nehmen zu müssen, und eine ellenlange "--exclude"-Liste für jedes rsync-Kommando ist auch nicht unbedingt dem Arbeitsfluß förderlich.

Wenn man, anders als Du, ungefähr 90% seiner Zeit auf der Kommandozeile verschiedener Systeme verbringt, dann summieren sich die kleinen Ärgernisse halt zu einem ziemlich großen Ärgernis.

MikeMuc

Wenn man ein Git oder ähnliches System verwendet und es läßt sich nicht "richtig" konfigurieren, dann hat ma wohl das falsche für die eigene Platform erwischt...

Die Sache mit dem Tellerrand, die Du gleich am Anfang geschrieben hast, ist nicht so falsch gewesen. In der Praxis hast Du nicht immer die Wahl, welche Tools Du nutzen kannst, welche die Gegenseite nutzt, welche die Gegenseite unterstützt und so weiter. Wie gesagt, die Aussage des Originalartikels bezüglich git kann ich nun gerade nicht nachvollziehen, aber auch da gibt es Szenarien (z.B. serverlose git-Synchronisation zwischen Mac und Linux), in denen das Problem zuschlagen kann.

MikeMuc

Ansonsten haben wohl die meisten System so ihre eigene "Pest". Da werden wir mit Leben müssen und jeweils einen Workaround um die spezifischen "Problemchen" anwenden müssen

Das ist jetzt fast schon ein "whataboutism". Nur weil alle Systeme derartige oder andere Probleme haben, ist es meines Erachtens noch lange nicht die richtige Strategie, auf die Fehler der anderen zu zeigen. Stattdessen sollte man an den eigenen arbeiten. Die Entschuldigung von Fehlern ist nicht gleichzusetzen mit ihrer Behebung, und die wäre Apples Aufgabe.

Anstatt z.B. Darstellungsoptionen an den Dateien bzw. Verzeichnissen festzumachen, wäre eine lokale Datenbank auf dem Client sinnvoller. Wenn die Optionen über mehrere Systeme gleich sein sollen, dann kann man die ggf. auch auf geeignetem Wege synchronisieren. Die schlechteste denkbare Option ist aber, sie wie derzeit in irgendwelchen versteckten Dateien auf dem Filesystem abzulegen und damit die geschilderten Probleme zu verursachen.

Ceterum censeo librum facierum esse delendum.

Marcel Bresink03.12.21 12:11

marm

.Trashes kein Papierkorb

Nein, das ist der Papierkorb, bzw. ein Teil davon, nämlich der Papierkorb für das Volume, auf dem dieser Ordner liegt. Aus der Summe aller dieser Ordner bildet der Finder dann den auf der grafischen Oberfläche dargestellten Papierkorb.

marm

.fseventsd irgendwas mit Logging

Nicht ganz. macOS braucht diesen Ordner zur Live-Nachverfolgung aller Änderungen auf diesem Volume. Unter anderem benötigt Spotlight (neben anderen Programmen) das, um zu wissen, wo der Spotlight-Index aufgrund neuer Daten nicht mehr gültig ist und überarbeitet werden muss.

marm

._ obskurer Kleinkram

Das sind die oben erwähnten AppleDouble-Dateien. Die gibt es nur auf "fremden" Dateisystemen (wie FAT), die selbst keine Erweiterten Attribute speichern können. Mithilfe dieser Dateien kann diese Funktion nachgerüstet werden, um wichtige Metadaten zu speichern.

MetallSnake03.12.21 12:20

Peter Eckel

Anstatt z.B. Darstellungsoptionen an den Dateien bzw. Verzeichnissen festzumachen, wäre eine lokale Datenbank auf dem Client sinnvoller.

Das hätte das Problemchen dass die Einstellung dann sofort verschwindet wenn Ordner umbenannten oder verschoben werden, und ein neuer Ordner mit einem alten Namen diese Einstellungen dann erbt. Und der Berg an Einstellungsleichen immer weiter anwächst.

Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.

Peter Eckel03.12.21 12:37

MetallSnake

Wir müssen hier ja grundsätzlich unterscheiden zwischen lokalen Verzeichnissen und solchen, die auf einem Server liegen.

Bei lokalen Verzeichnissen ist das von Dir geschilderte Problem lösbar, da das lokale Betriebssystem ja grundsätzlich involviert ist, wenn Umbenennungen stattfinden und so die entsprechende Datenbank aktualisieren kann.

Bei Verzeichnissen auf Servern ist das Problem genau so, wie Du es beschreibst, aber da sind die .DS_Store-Files ja nun auch keine wirklich gute Lösung, da verschiedene Nutzer des Servers ggf. verschiedene Präferenzen haben. Deswegen gibt es ja derzeit auch die Option, die Generierung der .DS_Store-Files abzuschalten. Konsequent wäre es also, bei Remote-Filesystemen entweder eine Heuristik zu finden, die Umbenennungen erkennt (was schwierig sein dürfte) oder dort eben keine Darstellungsoptionen abzulegen. Aber ja, das ist eine interessante Aufgabe, und vielleicht gibt es auch noch eine bessere Lösung.

Ceterum censeo librum facierum esse delendum.

hdrfoto.de03.12.21 15:16

Den original Artikel von Howard Oakley und die auf seiner Seite aufgelaufenen Kommentare dazu könnt ihr übrigens auf seinem Blog The Eclectic Light Company lesen.

Ich fände es sehr begrüßenswert, wenn bei zittierten/übersetzten Beiträgen auf MTN Quellenangaben zur Vorlage gleich im Text, möglichst am Anfang, stehen würden.

Fotografie ist mehr als den Auslöser zu drücken.

Mecki03.12.21 16:15

sondern die Nutzereinstellungen als erweiterte Ordner- und Dateiattribute in APFS ablegt.

Erweiterte Attribute kannte auch schon HFS, wenn also Apple das gewollt hätte, dann hätten sie das schon ewig so machen können. Außerdem sollen Finder Einstellungen ja auch auf USB Sticks erhalten bleiben, die oft mit FAT32 oder extFAT formatiert und da gibt es keine erweiterten Attribute. Und dann würde eine Dateibasierte Backup bzw. Clone Software diese Attribute nicht erfassen und sie wären dann nach einem Clone oder einem Restore verloren. Daher glaube ich nicht, dass Apple das vor hat. Im Gegenteil, unter Mac OS 9 hat Apple das so gemacht und hat dann bewusst auf Dateien umgestellt.

DS_Store: Was sind das für Dateien auf dem Mac?

Kommentare

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.