Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Datei ".DS-Store" nervt

Datei ".DS-Store" nervt

gickel04.03.1711:29
Hallo,

beim Umkopieren und Säubern meines NAS verliere ich sehr viel Zeit, wenn mir der Finder kurz vor Ende der Aktion mitteilt, dass es ".DS-Store" bereits auf dem Volume gibt, und den Kopiervorgang schadenfroh abbricht. Weiss jemand, wie ich diese reichlich störenden Dateien schad- und rückstandfrei entsorgen kann?
0

Kommentare

larsvonhier04.03.1711:32
Die Frage wäre eher: Gibt es clevere Backupprogramme, die sich an diesen Dateien (die macOS benötigt) nicht stört? Auf welchem OS findet denn der Kopiervorgang statt?
0
sffan04.03.1711:38
Ich kenne das Problem von USB-Sticks. Da möchte ich primär diese Systemdateien nicht draufhaben, da die vielleicht stören. Beispiel: Bei Firmware updates für TV, BlurayPlayer o.ä. Dafür hat sich bei mir CleanMyDrive bewährt. Es gibt noch diverse ähnliche Tools. Ob die für den Zweck auch geeignet sind, kann ich nicht beurteilen..
0
Serge
Serge04.03.1711:44
@gickel
Vielleicht ist es in deinem Fall eine gute Idee, dem Finder das .DS_Store schreiben einfach abzugewöhnen (im Terminal):

defaults write com.apple.desktopservices DSDontWriteNetworkStores TRUE

Die Dateien kann man natürlich nachträglich alle löschen (auch im Terminal):
cd /Volumes/"Extener Plattenname"
rm -rf .DS_Store

Wie immer, es ist gut, wenn man ein Backup hat, und ich gebe auch keinerlei Garantie, dass meine Kommandos oben alle korrekt sind. Wer im Terminal rumfummelt weiss hoffentlich, was sie/er macht
0
someone04.03.1711:49
Serge
Die Dateien kann man natürlich nachträglich alle löschen (auch im Terminal):
cd /Volumes/"Extener Plattenname"
rm -rf .DS_Store

Wie immer, es ist gut, wenn man ein Backup hat, und ich gebe auch keinerlei Garantie, dass meine Kommandos oben alle korrekt sind. Wer im Terminal rumfummelt weiss hoffentlich, was sie/er macht
Das Loeschen stimmt so kaeumlichst, auf jedem normalen Unix muss man das mit einem find kombinieren:
find . -name .DS_Store -exec rm -f {} \;
+1
rene204
rene20404.03.1711:55
mit dem TinkerTool von Marcel Bresink kannst Du das ganz bequem für Netzlaufwerke ausschalten....

http://www.bresink.com/osx/TinkerTool-de.html

„Gelassenheit und Gesundheit.. ist das wichtigste...“
+3
Black Mac
Black Mac04.03.1711:56
Für dieses unliebsame Beigemüse verwende ich seit langer Zeit “BlueHarvest” . Die Aktionen können klar definiert werden. Ausserdem kann ich damit Zip-Dateien bereinigen, bevor diese an Windows-Anwender gehen – und diese Dateien sind meistens voll mit diesem unsichtbaren macOS-Abfall.
„P.S.: Apple kann keine Dienste.“
0
gickel04.03.1712:00
larsvonhier
Die Frage wäre eher: Gibt es clevere Backupprogramme, die sich an diesen Dateien (die macOS benötigt) nicht stört? Auf welchem OS findet denn der Kopiervorgang statt?
NAS (derz. Quelle) ist Synology, Ziel ist 10.12.3…
+1
Jan-Henrik04.03.1712:31
Überflüssig sind diese DS_Store Dateien nicht, aber für Backup-Zwecke entbehrlich. Sie enthalten z.B. die Information, wie und wo sich ein Fenster öffnet und was man darin zu sehen bekommt. Sobald man einen Ordner am Mac öffnet, wird dort eine DS_Store Datei angelegt. Sie ist nur wenige Bytes lang. Als Dateien mit einem führenden Punkt sind sie Unix-konform unsichtbar. Für Windows-Systeme ist das jedoch lästiges Beiwerk, weil Windows diese Konvention nicht kennt und sie immer anzeigt. Das kleine Programm DSWipe entfernt diese Dateien.

http://www.intrarts.com/software.html
+2
gickel04.03.1713:08
rene204
mit dem TinkerTool von Marcel Bresink kannst Du das ganz bequem für Netzlaufwerke ausschalten....

http://www.bresink.com/osx/TinkerTool-de.html


Danke, Rene204, das hat wohl, für's erste zumindest, geholfen!
0
almdudi
almdudi05.03.1700:05
Jan-Henrik
Überflüssig sind diese DS_Store Dateien nicht, aber für Backup-Zwecke entbehrlich. Sie enthalten z.B. die Information, wie und wo sich ein Fenster öffnet und was man darin zu sehen bekommt.
Natürlich nicht, aber Leuten, die sich nicht so recht auskennen, dienen sie immer gut als Anlaß zu Apple-Bashing (die Benennung als "Abfall" sagt ja schon: keine Ahnung). Und wie man sie auf Sticks & Co. entfernt, wurde schon in gefühlt hundert Threads in den wichtigen Apple-Foren besprochen, nützt nichts, das Thema wird immer wieder gestellt.
W. erzeugt übrigens auch Dateien, die auf anderen Systemen stören, aber darüber beschwert sich niemand. M$ hätte schon seit ewigen Zeiten sich den UNIX-Konventionen anschließen können, punktbeginnende Dateinamen sind dort genauso selten sinnvoll wie auf unixoiden Systemen, aber die Arroganz der Marktbehrschung halt…
0
jogoto05.03.1705:04
War zwar nicht gefragt aber wenn ich was von abgebrochenen Kopiervorgängen lese, muss ich mal wieder das Terminal und „ditto“ anbringen.
ditto Quelle Ziel
So lange nichts zurückgegeben wird, läuft der Kopiervorgang fehlerfrei.
Fehler werden als Meldung in einzelnen Zeilen ausgegeben aber der Vorgang nie angehalten oder sogar abgebrochen. Die Liste der Fehler kann man sich danach in eine Textdatei kopieren und aufbewahren, fall nötig.
+2
gickel05.03.1710:09
almdudi
Und wie man sie auf Sticks & Co. entfernt, wurde schon in gefühlt hundert Threads in den wichtigen Apple-Foren besprochen, nützt nichts, das Thema wird immer wieder gestellt.

"hundert Threads in den wichtigen Apple-Foren" haut den Nagel auf den Kopf, und meiner tut noch weh von der Lektüre. Merke: Ich habe nach Empfehlungen gefragt, nicht alles, was "in den wichtigen Apple-Foren" die Foristen schreiben, funktioniert ja auch, wie daselbst zu lesen ist! Danke jedenfalls für die erfreulich zahlreichen Ratschläge!

TinkerTool erwischte ein paar böse Störenfriede, aber etliche meiner Daten sind aus dem letzten Jahrhundert. DSWipe war gründlich (Danke, Jan-Henrik) - und die Tags bleiben erhalten. Ob das auch für Kommentare etc. zutrifft, die ich nicht schreibe, kann ich nichts sagen, wäre aber froh, Genaueres zu hören, danke.
-2
Weia
Weia05.03.1721:15
gickel
TinkerTool erwischte ein paar böse Störenfriede, aber etliche meiner Daten sind aus dem letzten Jahrhundert. DSWipe war gründlich (Danke, Jan-Henrik) - und die Tags bleiben erhalten. Ob das auch für Kommentare etc. zutrifft, die ich nicht schreibe, kann ich nichts sagen, wäre aber froh, Genaueres zu hören, danke.
Hmmm, normalerweise ist Marcel Bresink (der Autor von TinkerTool) supergründlich, aber die Hinweise in dem (hier als Screenshot abgebildeten) TinkerTool-Fenster unter der Checkbox Bei einer Netzverbindung keine versteckten .DS_Store-Dateien anlegen stimmt so schon lange nicht mehr.

Richtig ist, dass OS X zu Anfangszeiten nicht so recht wusste, wohin Metadaten zu Dateien geschrieben werden sollten. HFS+ hatte kein (jedenfalls kein umfangreiches) Metadatensystem und die auf dem klassischen Mac OS üblichen Resource-Forks im Dateisystem wurden zwar noch verstanden, waren aber auf dem Weg der Ausmusterung, und so landeten einige Metadaten, z.B. die Kommentare zu Dateien, in den .DS_Store-Dateien. Dieses System war sehr fehleranfällig, denn wenn man z.B. eine Datei in einen anderen Ordner verschob, mussten ja die entsprechenden .DS_Store-Einträge in die .DS_Store-Datei des neuen Ordners umkopiert werden. Der Finder machte das, die entsprechenden Unix-Befehle im Terminal aber z.B. nicht. So gingen Kommentare etc. leicht verloren.

Besonders schlimm waren einige Software-Hersteller, denen der rechte OS-X-Durchblick fehlte und die deshalb für ihre Software Installer auslieferten, die es fertig brachten, sämtliche .DS_Store-Dateien im Dateipfad des zu installierenden Programms (also z.B. zwei .DS_Store-Dateien bei dem Pfad /Programme/Dienstprogramme/) mit den .DS_Store-Dateien desjenigen Rechners zu überschreiben, auf dem der Installer erstellt wurde. Und schwups, waren die eigenen Kommentare gelöscht …

Mit der Einführung von Spotlight und Time Machine in OS X 10.4 und 10.5 wurde HFS+ aber so aufgebohrt, dass es rundum Metadaten-fähig ist. Seitdem befinden sich die Metadaten (Kommentare, Tags, …) direkt im Dateisystem und nicht mehr in der .DS_Store-Datei des Ordners.

Man kann sich das leicht im Terminal mit dem Befehl xattr (extended attributes) und der Option -l (für list) ansehen:
xattr -l /Pfad/zu/der/Datei

Was mit den Metadaten passiert, wenn man die Dateien auf ein anderes Dateisystem als HFS+ kopiert, weiß ich aus dem Stegreif mangels eigener Erfahrung (ich verwende nur HFS+) jetzt allerdings nicht.

In den .DS_Store-Dateien befinden sich jetzt ausschließlich ordnerspezifische Finder-Einstellungen – welche Ansicht (Spalten, Liste, …), Größe des Finder-Fensters usw. und insbesondere alles, was man im Dialog Darstellungsoptionen (Command-J) so einstellen kann.
„🦖The dinosaurs invented Jesus to test our confidence in science“
+2
Weia
Weia05.03.1721:51
Weia
Was mit den Metadaten passiert, wenn man die Dateien auf ein anderes Dateisystem als HFS+ kopiert, weiß ich aus dem Stegreif mangels eigener Erfahrung (ich verwende nur HFS+) jetzt allerdings nicht.
Früher wurde dann auf anderen Dateisystemen ggf. zu einer Datei MeineDatei eine Datei ._MeineDatei (oder .__MeineDatei? – weiß nicht mehr genau) mit Metadaten angelegt – aber wie gesagt, wie der aktuelle Stand diesbezüglich ist, weiß ich jetzt nicht.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
X-Jo05.03.1722:09
gickel
[…]
TinkerTool erwischte ein paar böse Störenfriede, […]
Bitte in TinkerTool den Punkt „Bei einer Netzverbindung keine versteckten .DS_Store-Dateien anlegen“ sowie den Hinweis darunter noch mal sorgfältig lesen und versuchen zu verstehen!
0
PaulMuadDib06.03.1714:20
In diesem Zusammenhang eine Frage: ändert sich dieses Verhalten evtl. mit Apples neuem Filesystem? Zwar haben diese Dateien erst mal nix mit dem FS zu tun, jedoch könnten ja Funktionen enthalten sein, die diese Dateien völlig verbergen. Weiß da evtl. jemand was genaueres drüber?
+1
Bodo_von_Greif06.03.1714:33
@someone
rm -rf .DS_Store

ist imho völlig richtig, für alle Unixe und look alikes wie z.B. Linux

Gruss,

Bodo
„[x] nail here for new monitor“
0
Weia
Weia06.03.1714:47
Bodo_von_Greif
rm -rf .DS_Store

ist imho völlig richtig, für alle Unixe und look alikes wie z.B. Linux
Nö, ist es nicht.

Das -f kann man eh vergessen in unserem Zusammenhang, das würde nur dazu dienen, auch schreibgeschützte Dateien ohne Nachfrage zu entfernen.

Und rm -r bedeutet lediglich, dass ein Ordner mitsamt Inhalt gelöscht werden kann, aber nicht, dass die Dateihierarchie innerhalb eines Ordners gezielt nach Dateien eines bestimmten Namens durchsucht werden kann.

Wäre also .DS_Store ein Ordner mit Inhalt, dann könntest Du ihn nur mit rm -r löschen, nicht mit rm. Ist hingegen .DS_Store (wie es ja tatsächlich der Fall ist) eine Datei, so hat das -r keinerlei Effekt. Es wird in jedem Fall aber nur der Ordner oder die Datei .DS_Store im aktuellen Ordner gelöscht, und nicht etwa Unterordner nach weiteren gleichnamigen Dateien/Ordnern durchsucht. Dazu benötigt man in der Tat
find . -name .DS_Store -exec rm {} \;
„🦖The dinosaurs invented Jesus to test our confidence in science“
+1
Weia
Weia06.03.1715:06
PaulMuadDib
In diesem Zusammenhang eine Frage: ändert sich dieses Verhalten evtl. mit Apples neuem Filesystem? Zwar haben diese Dateien erst mal nix mit dem FS zu tun, jedoch könnten ja Funktionen enthalten sein, die diese Dateien völlig verbergen. Weiß da evtl. jemand was genaueres drüber?
Was wäre das für ein seltsames Dateisystem, das Dateien verbirgt? Ein Dateisystem sollte das exakte Gegenteil sein – so transparent wie möglich.

Die Frage ergibt also keinen Sinn.

Um Dateien vor dem Blick des „normalen Anwenders“ zu verbergen, gibt es in Unix seit Urzeiten die bewährte Konvention mit dem Punkt zu Beginn des Dateinamens. Das hat erstens nichts mit einem Dateisystem zu tun, und zweitens: Warum sollte man das ändern?

Falls Dir sowas vorschwebt wie Metadaten: Das ginge jetzt bereits genauso, hat also eben nichts mit dem Dateisystem zu tun. Der Finder könnte, wenn seine Programmierer es wollten, auch in HFS+ alle in den .DS_Store-Dateien gespeicherten Informationen stattdessen als Metadaten des entsprechenden Ordners abspeichern. Sie wollen aber offenbar nicht. Mit dem Dateisystem hat das nichts zu tun.

Und falls es Dir um die Sichtbarkeit dieser Dateien auf anderen Betriebssystemen ginge: Das Problem würde damit ebenso wenig gelöst. Denn wenn die Daten, die sich jetzt in den .DS_Store-Dateien befinden, stattdessen in Ordner-Metadaten geschrieben würden, dann müssten diese Ordner-Metadaten auf anderen Betriebssystemen (mit anderen Dateisystemen) ja wiederum in – .DS_Store-Dateien vergleichbare – Dateien ausgelagert werden, um nicht verloren zu gehen.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.