Werden die dort gespeicherten Ansichtsoptionen irgendwann als Dateiattribut in APFS gesichert oder werden wir uns auf ewig mit diesen Dateien rumschlagen müssen?

Ich habe es nicht aktiv verfolgt, ob in einem WWDC-2024-Video dazu irgendeine Aussage gefallen ist – ich vermute aber stark, dass die uns mindestens bis 2040 begleiten werden Hat doch auch schon in der Vergangenheit SUPER funktioniert und keine Probleme verursacht!

Sehr schade. Hätte gehofft das sich in dem Bereich auch etwas getan hat.

Das ist das Apple-Äquivalent zur PS/2-Buchse beim PC...

Nein, denn der Finder soll ja auf jedem beliebigen Dateisystem funktionieren, nicht nur auf APFS oder Dateisystemen, die native Attribute unterstützen.

Und was sollte der Vorteil sein? Außer einem (normalerweise unsichtbaren) Dateieintrag im jeweiligen Ordner würde das keinen Unterschied machen.

Marcel Bresink
Die unsichtbare .DS_Store-Datei ist aber mehr als nervig, wenn du z.B. Ordner auf Windows-Systeme kopierst usw.

Das geht nur an der Fragestellung vorbei, denn den Inhalt der .DS_Store-Datei als Attribut zu speichern, würde bedeuten, dass in diesem Fall statt der versteckten .DS_Store-Datei im jeweiligen Ordner nun eine versteckte "Punkt-Unterstrich-Datei" (._Beispiel) im Ordner eine Ebene höher angelegt werden müsste.

Um das Problem zu lösen, müsste man eine Grundeigenschaft des Finders aufgeben, nämlich im Vorhinein eine Ansicht für einen Ordner vorgeben zu können, die für alle Benutzer und alle Macs gilt.

Zumindest auf Netzlaufwerken kann man das Schreiben von DS_Store ausschalten:

Für die Speicherung der Ordner-Ansicht ist das sinnvoll. Nur leider hat die .DS_Store-Datei mehr Aufgaben als nur das.

Ich würde es begrüßen, wenn die Finder-Kommentare primär als Attribut der Datei und nicht in der .DS_Store-Datei gespeichert würden. Derzeit werden sie dort gespeichert und zusätzlich in com.apple.metadata:kMDItemFinderComment
als Attribut der Datei abgelegt. Schreibe ich meine Informationen in com.apple.metadata, kann ich mich nicht darauf verlassen, dass sie auch in der .DS_Store-Datei enthalten sind. Wenn ich eine Datei aus DevonThink exportiere, wird der Kommentar in der .DS_Store-Datei gespeichert. Synchronisiere ich die Datei auf ein NAS, eine Cloud etc., geht das Attribut verloren. Mit den Tags/Schlagwörtern verhält es sich nicht anders.
Hinzu kommt, dass es ähnliche Dateiattribute gibt, die nicht in der .DS_Store-Datei gespeichert werden, aber von kaum einem Programm unterstützt werden. Das ist also ein durch Apple lösbares Problem.

Vor 2 Jahren hat MacTechNews ähnliche Überlegungen angestellt, siehe letzter Abschnitt "In Zukunft als APFS-Metadaten?"

Das ist zu 100% inkompatibel mit den üblichen Filesharing Protokollen. Weder SMB noch NFS unterstützen das, so dass die Dateien verstümmelt würden.

Das ist eine Datei - die aber, sofern sie klein genug ist nur ein Eintrag im Directory ist mit den Daten als extended attribute. Das wird schon seid HFS+ unterstützt.
Ändert aber nicht daran, dass es eine Datei ist - die man aber einfacher entfernen kann als extended attributes.

Ich weiß jetzt nicht, wie ich die Aussage von Dir einordnen soll. Ich schreibe hier aus Anwender-Sicht ...
Die Finder-Kommentare werden heute bereits sekundär als Attribut der Datei gespeichert und zusätzlich gibt es noch das Comments-Attribut der Datei.

Bei Synchronisierungen muss diese .DS_Store stets ausgeschlossen werden, weil oft eine Änderung im Verzeichnis angezeigt wird, obwohl sich an den Datei und Attributen nichts geändert hat. Finde ich auch nicht so praktisch (Stichwort Revision).

Genau so wird es seit vielen Jahren gemacht.

Das ist richtig. Das ist eine Kompatibilitätsfunktion, um alte Versionen des Finders weiterhin unterstützen zu können. In alten Versionen von Mac OS X gab es keine Erweiterten Attribute.

Das ist ein generelles Problem, wenn man Macintosh-Besonderheiten auf fremden Dateisystemen speichert. In der Regel lässt sich das lösen, wenn man ein Netzwerkprotokoll, bzw. Synchronisationsverfahren verwendet, was mit den jeweiligen Dateieigenschaften umgehen kann.

Darum ging es ja. Die .DS_Store-Dateien sind eine spezielle Lösung für Ordner-Ansichtsoptionen des Finders. Für andere Zwecke und andere Programme gibt es Erweiterte Attribute. Es gibt historische Gründe, weshalb beide Verfahren voneinander getrennt sind. Aber beide Techniken können ähnliche Probleme machen oder deren Daten bei bestimmten Operationen verloren gehen.

Bis auf das Wort "primär", um das es mir geht. Der Finder liest die Info aus .DS_Store und nicht aus den extended attributes. Beides sollte die gleiche Information haben, aber wenn ich direkt in die extended attributes schreibe, wird .DS_Store nicht geändert.
So jetzt zumindest meine Erfahrung beim Ausprobieren, wie ich am besten mit Tags und Kommentaren arbeite.

Das stimmt inzwischen nicht mehr.
Apple unterstützt seit macOS 11 Erweiterte Attribute über NFSv4. Dies gilt auch (schon länger) für SMB, wenn die Option "stream support" eingeschaltet wird und der Server anzeigt, dass er "NTFS Alternate Data Streams (ADS)" unterstützt.

Kannst Du das ausführen? Das klingt interessant. Wie teste ich, ob die Funktion für SMB aktiviert ist?
Vielleicht sollte ich mir doch mal NFS für Synology anschauen.

Das Problem ist, dass weder bei SMB oder NFS Erweiterte Attribute von Anfang an (Marcel Bresink hat ja freundlicher Weise darauf hingewiesen, dass das mittlerweile möglich ist.) Teil des Protokolls waren. Da Apple selbst keine Fileserver mehr produziert, muss man letztlich auf Systeme anderer Hersteller zurückgreifen, und da fangen dann die Probleme an. Die minimal notwendige NFS Version ist 4.2, und diese wird erst ab Linux Kernel Version 5.9 unterstützt.

Um das etwas einzuordnen. Aktuell werden drei Red Hat Enterprise Linux Version gewartet: 7, 8 und 9. Der Support für 6 endete gerade. Nur RHEL 9 hat einen Linux Kernel der ausreichend neu ist, um die erweiterten Attribute über NFS zu unterstützen.

Dazu kommt die Thematik, ob es in einem größerem Umfeld überhaupt gewünscht ist auf so eine neue NFS Version zu setzten, weil es sonst möglicherweise Probleme mit anderen Maschinen im Firmennetz gibt. Sprich gibt es überhaupt Support für NFSv4.2 für AIX und Solaris oder für den Mainframe?

Daher ist es auf absehbare Zeit angebracht weiterhin die Dateiattribute so speichern zu können, dass das System nicht auf erweiterte Attribute angewiesen ist, sondern auch mit „flachen“ Dateien zurecht kommt.
Ok, wusste ich nicht. Allerdings ist es NFSv4.2 und nicht NFSv4, was die Verfügbarkeit nicht unerheblich einschränkt.

Danke für die Erläuterungen. Ich bin neu bei Linux, aber mit Endeavouros und Fedora nutze ich zwei Distributionen mit aktuellem Kernel. MacOS ist noch bei NFSv4. Heißt das ich könnte Dateiattribute nutzen mit Linux + NFSv4.2 und MacOS + SMB? Das wäre für meine Text- und E-Mail-Dateiablage sehr hilfreich.

NFS habe ich soeben testweise auf dem Mac ans Laufen bekommen. Ist aber noch halb so schnell wie SMB (sofern der Test was taugt).

Nö. Wäre ja auch möglich, die Attribute an einer völlig anderen Stelle abzulegen – Spotlight speichert ja die Metainformationen zu Dateien auch nicht neben den Dateien.

Vielleicht etwas spitzfindig, aber Spotlight speichert lediglich den Index separat von den Dateien. Alle Metainformationen sind in den Dateien enthalten oder hängen als Xattr (Tags, Kommentare) dran. Der Index sammelt Metainfos nochmals an einem zentralen Ort und dient lediglich der schnelleren Suche, aber ich glaube, da erzähle ich niemanden was Neues.

Ja eben nicht. Die FinderComments sind in .DS_Store oder als extended attributes (xattr) in com.apple.metadata:kMDItemFinderComment in der Datei. Genauso die Tags. Der Finder ignoriert xattr.
Bei Spotlight bin ich mir nicht sicher. Soweit ich das verstanden habe sucht Spotlight in xattr.
Das ist jetzt off-topic, aber NFS läuft bei mir ein ganzes Stück schneller als SMB
Mein erster Test lief über WLAN, weil ein Switch ausgefallen war. War mir gar nicht aufgefallen.

Nein, das stimmt so auch nicht, es ist komplizierter. NFSv4 fordert grundsätzlich, dass Erweiterte Attribute unterstützt werden sollen. Falls der NFSv4-Server ein Linux-Server ist, dann ist es richtig, dass Linux diese Forderung erst dann umsetzt, wenn der Server NFSv4.2 unterstützt, was wiederum ab Linux 5.9 möglich ist. macOS unterstützt dagegen client-seitig nur das klassische NFSv4 (d.h. Version 4.0), und als Server nur NFSv3.

Nicht wirklich. Die Kommentare des Finders, die früher Spotlight-Kommentare hießen, befinden sich standardmäßig im Erweiterten Attribut "com.apple.metadata:kMDItemFinderComment" an der jeweiligen Datei. Um die Kompatiblität mit alten Versionen von Mac OS X sicherzustellen, werden die Kommentare im Moment zusätzlich auch noch in der .DS-Store-Datei des jeweiligen Ordners abgelegt.

Was soll das bedeuten? Der Finder ist doch der größte Nutzer von Erweiterten Attributen.

Das wäre zwar theoretisch denkbar, aber um die gewünschte Funktionalität zu erreichen, muss diese Stelle ja auf jedem beliebigen Betriebssystem und jedem beiliebigen Dateisystem erreichbar und beschreibbar sein. Das über eine versteckte Datei zu machen, ist eigentlich die einzige portable Möglichkeit, die in der Praxis umsetzbar ist.

Aber Spotlight erfordert einen ständig laufenden Serverprozess auf dem betroffenen Betriebssystem, der seine Dateisysteme live in Echtzeit überwachen und die Daten fortlaufend in einer geschützten Datenbank nachsynchronisieren muss. Aufwändiger geht es kaum.

Sorry, ich weiß jetzt, was Du meinst, das war ein Missverständnis. Es ist tatsächlich so, dass die .DS_Store-Dateien immer noch die primäre Quelle der Kommentare für den Finder sind. Dass Spotlight jede Änderung des Kommentars automatisch in ein Erweitertes Attribut übernimmt, ist quasi eine indirekte Nebenwirkung von Spotlight, nicht eine direkte Funktion des Finders.

Nur leider funktioniert die umgekehrte Richtung nicht. Wenn ich also den Eintrag des FinderComments vom Erweiterten Attribut ändere, dann habe ich als Resultat zwei unterschiedliche Einträge in xattr und in .DS_Store.
Der Finder zeigt weiterhin den alten Eintrag von .DS_Store an.

sudoRinger
schönes Beispiel eben dafür, das man den Gaul nicht von hinten aufzäumen soll.
Wenn der Finder deine Änderungen „lesen“ können soll, mach es andersrum wie bisher. Wenn dir der Finder egal ist, bleib bei deiner Vorgehensweise.
Ich hoffe, Apple hat das auch entsprechend irgendwo (so rum) dokumentiert und Marcel mußte das nicht mühselig selber ausklamüsern.

Ich mache es ja richtigrum. Dafür probiere ich solche Dinge aus.

Dann würden die Informationen aber nicht mittransportiert werden, wenn Verzeichnisse mit enthaltenen Dateien auf ein anderes System kopiert werden. Das kann ja durchaus erwünscht sein

Soeben habe ich Tags und Finder-Kommentare mit der Synology getestet. Ich war stets davon ausgegangen, dass dies nicht funktioniert. Es klappt, aber es kommt auf die Details an.

1. Schritt: Ich habe eine Textdatei auf dem Mac im Finder mit einem Tag und einem Finder-Kommentar versehen (also in .DS_Store).
2. Schritt: Kopie der Datei auf ein Synology-Order, welches per SMB 3 gemountet ist, und eines welches per NFSv4 gemountet ist. In Finder sehe die Tags, aber nicht die Kommentare.
3. Schritt: beide Kopien zurück zu Downloads. Tags blieben erhalten. Finder-Kommentar ist nicht mehr sichtbar im Finder (fehlt also in .DS_Store), aber der Kommentar blieb in xattr erhalten.
4. Schritt: Kopie in Devonthink. Finder-Kommentar ist in Devonthink sichtbar.
5. Schritt: Export aus Devonthink zu Downloads. Finder-Kommentar ist nun auch wieder im Finder sichtbar (also in .DS_Store), weil Devonthink den Eintrag von xattr in .DS_Cloud schreibt.

Fazit
Das wäre alles weniger obskur, wenn der Finder den Eintrag aus xattr zeigen würde und nicht aus .DS_Store.
Das ist bei Apple alles nicht dokumentiert. Die besten Hinweise dazu finden sich auf der Seite Eclecticlight. Oakley empfiehlt aber auf com.apple.metadata:kMDItemComment auszuweichen, was nochmal was anderes ist als der Eintrag in .DS_Store und der FinderComment in xattr.

Sicher? Ich lese immer nur was von Ordner-Ansichten.
Unter Windows ist es ganz einfach - da stelle ich einmal ein, wie ich die Explorer-Ansicht haben möchte und dann ist das auch immer so. Listenansicht, alphabetisch sortiert, fertig.
Nervt mich beim Finder sehr, dass jeder Ordner erstmal aussieht wie hingewürfelt.

ja.
Da kann geholfen werden. Öffne die Darstellungsoptionen ⌘ + J.

Danke für das Berichten, sudoRinger!
Ich habe vor Jahren die Konsequenzen daraus gezogen und setze auf DAS und nicht auf NAS. Ich weiß, dass das für viele hier im Forum keine Lösung ist, weil die Daten permanent im Netzwerk verfügbar sein müssen; für mich ist das aber nur selten von Bedeutung; insgesamt überwiegen für mich die Vorteile eines DAS.

Ich freue mich immer, unter macOS für besondere Ordner speziell eingerichtete Ansichten zu haben.
Jedes Mal wenn ich nur an Windows denke (das ich regelmäßig widerwillig benutze) sehe ich da ein zusammengewürfeltes Frankenstein-GUI: je tiefer man gräbt, desto gruseliger wird es (will die Frankenstein-Metapher jetzt aber nicht überspannen...)

Danke!

Da ich an diversen Rechnern arbeite und Daten wild hin- und herschiebe, nutze ich Tags und Kommentare überhaupt nicht. (Ausnahme mp3-Tags)
Ich bevorzuge eindeutige Dateinamen, die Datum und Inhalt sofort erkennen lassen und beim Versand auf egal welchem Weg nicht verlorengehen.

Falls man die individuellen Einstellungen loswerden will, kann man auch alle DS_Store-Dateien löschen:


Der Befehl grast den aktuellen Ordner im Terminal samt Unterordner ab.

@Nebula
Dafür gibt es ja den alternativen Befehl "dot_clean". Ist IMHO einfacher zu benutzen

Kapitän

Und was ist das Problem an den verstecken DS Store Files, habe seit Mac OS X 10.0, bis heute keine Probleme damit?

Auch auf Windows System keine Probleme, denn wie auch in macOS sind diese Dateien auch dort unsichtbar.

apple@wien gesucht und das hier auf MTN gefunden

Der ist doch für die AppleDouble-Files mit ._ gedacht, oder nicht?