Welcher Daemon erzeugt die @eaDir Verzeichnisse?

[scythe42]

Welcher Daemon, wenn man APF eingeschaltet hat, ist dafür verantwortlich dass diese @eaDir Verzeichnisse überall erstellt werden? Geht mir gewaltig auf die Nerven und will ich loswerden. AFP ist nur wg. Lion und TimeMachine eingeschaltet.

Denke mal es ist wohl ein Teil eines Index Service, der dort für extended Attribute oder AFP Dictioniaries was anlegt. Brauch ich nicht, will ich nicht bzw. maximal nur in bestimmten Verzeichnissen. Aber bitte doch nicht mein ganzes System zumüllen, zumal auf der DS z.B. Sickbeard wg. dem @ im Verzeichnisnamen nicht richtig will, wenn man neue Shows importiert. Fliegt bei seinem Find wg. dem @ am Anfang im Verzeichnisnamen auf die Schnauze und bricht das Traverse des Verzeichnisses ab.

Also wie bekomme ich den Kram unter Kontrolle?

 

[Trolli]

Benutz doch einfach SMB statt AFP. Die @eaDir Verzeichnisse werden bei allen anderen Protokollen ausgeblendet. Und ja, die werden zum Teil bei der Indexierung angelegt, z.B. liegen die Vorschaubilder für die Photo Station in solchen Verzeichnissen. Andere wiederum werden über den PC erzeugt, weil dort die erweiterten Dateieigenschaften abgelegt werden.

 

[DKeppi]

Die @eaDir Verzeichnisse werden bei allen anderen Protokollen ausgeblendet.

Stimmt, aber geben tut es sie trotzdem.

 

[itari]

Die @eaDir-Geschichte ist eine Möglichkeit, zusätzliche Informationen zu einer Datei zu speichern, um z.B. die zusätzlichen Möglichkeiten eines anderen Ty<ps von Dateisystem nachzubilden. So gibt es bei NTFS und auch bei OSX die Möglichkeit, mehrere Data-Streams (Dateien in Dateien, alternate Datastreams = ADS) zu erzeugen. Auf der DS wird das hauptsächlich für mediale Zwecke verwendent: Vorschaubilder/Thumbs. Also nichts für irgendeinen Indexdienst.

Wenn man solche Dateisysteme auf Bit genau kennt, kann man das eine oder andere löschen; ansonsten würde ich sagen: Finger weg davon und sich darauf einrichten, damit zu leben. Solche Geschichten finden übrigens bei den meisten Betriebssytem statt, werden nur oft nicht mit den herkömmlichen Dateiexplorern angezeigt oder gut versteckt ... warum weiß keiner genau. Ich finde, man sollte das lieber alles offen legen, damit auch der Normalsterblich sieht, wie hochkomplex solche Dateisystem sind ...

Wenn du damit nicht leben kannst, dann schaffe dir ein anderes System an von einem anderen Hersteller an (das ist ein gut gemeinter Tipp , weil du dich sonst immer damit Herumärgern werden wirst).

Itari

 

[scythe42]

Unter Lion braucht's AFP. Jedenfalls hab ich es nicht wie unter Snow Leopard nach meinem Upgrade vor ein paar Wochen auf mehr hinbekommen. Hat sich wohl irgendwas im Time Machine App geändert. Einziger Grund warum AFP bei mir an ist. Muss ich aber noch gucken, ob ich das nicht auch noch loswerden kann.

Ich hab es soweit mit viel Googeln hinbekommen:

• @eaDir von Rsync ausschliessen lassen (für Backups)
• Auf dem Mac: defaults write com.apple.desktopservices DSDontWriteNetworkStores true
• Auf Win7: "Saved taskbar thumbnail previews" in den Performance Settings abgeschaltet
• Auf Win7: "Show thumbnail instead of Icon" in den Performance Settings abgeschaltet
• Auf Win7: Mittels Policy "Turn off the caching of thumbnails in hidden thumbs.db files" abgeschaltet

So nun scheint Ruhe zu sein. Kein @eaDir ausser, die Synoshare Teile, keine .DS_Store, keine Thumbs.db mehr.

Nur noch beim Kopieren von Dateein über SMB taucht noch vereinzelt ein @eaDir auf, wo ich sie nicht haben will. Scheinen wohl ADS Daten zu sein. Aber die lass ich mittels Cronjob, da wo sie nichts zu suchen haben löschen.

Verbleibt noch ein bisschen an der Bash schrauben, damit die verbleibenden Dateien mir nicht auf den Keks gehen.

PS: Bin mal gespannt was passiert, wenn ich den iTunes Service mal einschalte...

 

[jan_gagel]

[...] Ich finde, man sollte das lieber alles offen legen, damit auch der Normalsterblich sieht, wie hochkomplex solche Dateisystem sind ... [...]

Und dann wird von Unwissenden da drin rumgefummelt und so einige Sachen weg-optimiert. Wenns dann klemmt wars das sch* Betriebssystem. Nee, ist schon ganz gut, daß die Dinger nicht angezeigt werden. Schön wäre es, wenn es in der DSM-Oberfläche entsprechende Einstellungen gibt, ob solche speziellen Attribute gespeichert werden sollen, oder nicht.

 

[itari]

Und dann wird von Unwissenden da drin rumgefummelt und so einige Sachen weg-optimiert. Wenns dann klemmt wars das sch* Betriebssystem. Nee, ist schon ganz gut, daß die Dinger nicht angezeigt werden. Schön wäre es, wenn es in der DSM-Oberfläche entsprechende Einstellungen gibt, ob solche speziellen Attribute gespeichert werden sollen, oder nicht.

Also ich find es nicht schlecht, wenn man zeigt, dass es 2.345 statt 11 Kleinteile gibt, aus denen der Motor besteht. Das bedeutet ja nicht unbedingt, dass man den User daran herumschrauben lassen muss. Aber die Fragen kommen irgendwann sowieso, also warum dann nicht gleich in einem Background-Manual erklären ...

Itari

 

[Solear]

Gibt es schon neue Erkenntnisse, welche Dienste genau die @ea Verzeichnisse anlegen? Mich nerven die auch gewaltig. Kann es sein, dass die zB von der PhotoStation angelegt werden?

 

[cp389]

Definitiv nicht direkt von der PhotoStation, denn die hatte ich nie installiert. Dennoch hab ich diese Verzeichnisse überall.

 

[Frogman]

Ähm, ihr habt aber schon oben die Posts gelesen, insbesondere auch den von itari?
Welcher Dienst? Bei der Medienindizierung/Photokonvertierung beispielsweise werden solche @eaDir angelegt und befüllt, auch ohne Photostation, denn Thumbnails werden auch für andere Apps wie z.B. den Medienserver bereitgestellt.

 

[Solear]

Doch, ich hab alles gelesen, habe aber herausgelesen dass nicht genau klar ist welcher Dienst verantwortlich ist (unter anderem der Medienserver).
Wenn in den Systemeinstellungen/Medienbibliothek kein Verzeichnis und keine App eingetragen ist dürften keine @ea-Dirs mehr auftauchen? Muss ich mal testen. Plex wird ja hoffentlich ne zentrale DB nehmen.

 

[dil88]

Meines Wissens die Medienindizierung. Die Thumbnails, die z.B. von PhotoStation erzeugt werden, landen wohl auch dort.

 

[jan_gagel]

Soviel wie ich beim Überfliegen gelesen hab, weil es mich ja eher weniger interessiert, landen in diesen berüchtigten Verzeichnissen Datei-Fragmente und Dateien, die für verschiedene Dateisystem-Funktionen benötigt werden, so aber nicht direkt im ext3 / 4 abgebildet werden können. Es ist also nicht ein einziger Dienst, der dort was ablegt sondern unterschiedliche Dienste legen unterschiedliche Daten ab. Was da so im Einzelnen abgelegt wird, müßte man erstmal analysieren. Ich würde jedenfalls davon die Finger lassen, sonst könnte es sein, daß die ein oder andere Funktion nicht mehr geht. Vielleicht werden dort auch die ACLs abgelegt..

Ich denke, es wird sich nicht eine Funktion finden, die man abschalten kann und hat dann diese Verzeichnisse nicht mehr. Vielleicht braucht der afpd diese Verzeichnisse deutlich mehr als Samba?

 

[Balgenbruder]

Hab ein aehnliches Problem.
Ich bin von der Cloudstation der Syno umgestiegen auf Bittorrent Sync.
Mit der Cloud von Syno hatte ich bei 2,1TB Daten nach 6 Monaten 4,7TB Platz belegt schoen steigend.
Leider synct Bittorrent die eaDIRs in die Macs rein obwohl sie in der syncignore ausgeschlossen werden.
Das Einzige was bei mir noch laeuft ist der Medienserver, den brauche ich einfach.
Keine Ahnung was die eaDIRs bewirken aber bei 1TB an Bilderdaten ueber zehn Jahre mit Unterverzeichnissen pro Tag sind eine entsprechende Anzahl eaDIRs einfach schxxxxx.

Ich hab schon gegoogelt und Konsolenbefehle eingegeben die angeblich die Dienste abschalten sollen.
Leider kam die Rueckmeldung das diese Dienste nicht existierenn.
Nach dem Loeschen aller eaDIRs per Konsole waren diese nullkommanix wieder da.

 

[iOOi]

.

Immer noch so?
Nebenwirkungen?

Disable indexing and generation of @eaDir directories on Synology NAS

https://mikebeach.org/2012/12/12/di...eration-of-eadir-directories-on-synology-nas/

 

[iOOi]

.


Auch meine DS ist mit @eaDir angefüllt.


Getting rid of the @eaDir folders on Synology NAS DSM

https://mikebeach.org/2012/12/12/getting-rid-of-the-eadir-folders-on-synology-nas-dsm/

 

[goetz]

Hallo,
der Blogeintrag ist 6 Jahre alt, das angegebene Verzeichnis existiert nicht mehr.

Gruß Götz