temp-Daten großzügig via Cronjob + Skript löschen, spricht was dagegen?

[mama-YT]

Wir haben in unserem kleinen Unternehmen ein DS415+ erfolgreich in Betrieb genommen und die Performance begeistert.

Was allerdings mir allerdings unangenehm auffällt: Das Dateisystem wird mit unnützen Metadaten zugemüllt, bisher aufgefallen sind mir: .DS_Store, .TemporaryItems, @eaDir.
.DS_Store: Obwohl die die Mac-Clients entsprechend konfiguriert wurden (defaults write com.apple.desktopservices DSDontWriteNetworkStores true) entstehen die Dateien trotzdem. Zugriff ist via SMB.
@eaDir: Ich verwende nur gemeinsame Ordner, nicht mit besonderen Namen (photos usw) und verwende die Photostation auch nicht. Trotzdem tauchen diese Daten überall auf.

Hauptsächlich stört mich daran, dass diese unzähligen Meta-Daten das Time Backup auf das 2. NAS massiv aufblähen werden. Auch der normale Backup Job auf externe USB wird durch zahlreiche Vergleiche hinausgezögert.

Hier habe ich ein Skript gefunden:
http://www.meintechblog.de/2013/04/...dauerhaft-von-nervigen-temp-dateien-befreien/

find /volume1/ -depth \( -name '.@__thumb' -o -name '.DS_Store' -o -name '.AppleDouble' -o -name ':2e*' -o -name '~$!#~*' -o -name '.TemporaryItems' -o -name '.apdisk' -o -name '@eaDir' \) -exec rm -rf {} \;

Spricht etwas dagegen das jede Nacht um 22 Uhr laufen zu lassen um aufzuräumen? Wird irgendwas von den Metadaten tatsächlich benötigt, wenn man nur mit gemeinsamen Ordnern zur zentralen Dateiablage arbeitet?

 

[Merthos]

In den eaDir liegen u.a. auch erweiterte Rechte (ACLs), welche sich nicht im Linux-Filesystem abbilden lassen. Wenn das kein Problem ist, nur zu.

 

[mama-YT]

Die Rechteverwaltung erfolgt allein über die Gruppenkonfiguration im synology und damit denke ich beim Zugriff über SMB. Daher dürften, soweit ich das verstehe, die Dateien selbst nicht mit Rechten versehen sein.

Die Umgebung ist insgesamt heterogen: Verschiedene Linuxe, MacOSX, iOs und Windows Versionen greifen darauf zu.

 

[dil88]

Die Rechteverwaltung erfolgt allein über die Gruppenkonfiguration im synology und damit denke ich beim Zugriff über SMB. Daher dürften, soweit ich das verstehe, die Dateien selbst nicht mit Rechten versehen sein.

Bzw. sollten dann die möglicherweise vorhandenen ACL-Informationen irrelevant sein. Probiere es einmal aus und berichte bitte.

 

[mama-YT]

Folgendes Skript wird nun nächtlich wie Cronjob ausgeführt und scheint zu funktionieren:

find /volume1 -depth \( -name '.@__thumb' -o -name 'Thumbs.db' -o -name '.DS_Store' -o -name '.AppleDouble' -o -name ':2e*' -o -name '~$!#~*' -o -name '.TemporaryItems' -o -name '.apdisk' -o -name '@eaDir' \) \( -type d -o -type f \) -exec echo {} \; -exec rm -rf {} \; > /volume1/95_wartung/delete_temporary_files.sh.$(date +%Y-%m-%d).log

Ggfs. anzupassende Pfadangaben sind oben orange markiert.

Rahmenbedingungen:
- Skript gespeichert in /volume1/95_wartung/delete_temporary_files.sh
- Skript wird unter Geplante Aufgaben mit Administratorrechten ausgeführt
- Log-Dateien werden in /volume1/95_wartung/ geschrieben

Es erstellt eine Log-Datei mit dem jeweiligen Datum.

 

[dil88]

Klasse, danke dafür!

 

[mama-YT]

Nach einigen Tagen im Betrieb bin ich in diesem Zusammenhang auf 2 Probleme gestoßen, das zweite davon ist gravierend:

1. Wenn MacOSX Benutzer Ordnern Farben zuweisen wird das in eaDir gespeichert. Das Löschen dieser führt dazu, dass die Farbzuweisung verloren geht. Hätte das jetzt in .DS_Store erwartet, ist aber nicht so.
2. Auf docx-Dateien kann mit Win8.1 ohne eaDir praktisch nicht zugegriffen werden: Umbenennen geht zwar, kopieren und öffnen jedoch nicht (!). Ein MacUser muss dann die Datei öffnen und speichern, anschließend kann man sie auch mit Win8.1 wieder öffnen & kopieren. An dem Besitzer liegt es leider nicht (was naheliegend wäre) sondern tatsächlich in den in eaDir gespeicherten Informationen. Andere Dateien, wie XLSX, PDF, JPG, ... sind davon nicht betroffen.

Das Problem mit den docx-Dateien wird gelegentlich mal beschrieben, selten jedoch eine Lösung.

Nun könnte man zwar sagen ist nicht so wild, einfach eaDir nicht löschen. (Absatz ist falsch) ABER: Das Problem ist insbesondere dann kritisch, wenn von einer bestehenden Umgebung auf ein NAS migriert wird. Dann sind diese eaDir Informationen (je nach Vorgehen) nämlich nicht gesetzt und docx-Dateien unter Win8.1 (vermute mal bei älteren auch) erstmal nicht zugreifbar.

Alle Zugriffe erfolgten mit SMB.

Das Aufräum-Skript sieht nun daher so aus:
find /volume1 -depth \( -name '.@__thumb' -o -name 'Thumbs.db' -o -name '.DS_Store' -o -name '.AppleDouble' -o -name ':2e*' -o -name '~$!#~*' -o -name '.TemporaryItems' -o -name '.apdisk' \) \( -type d -o -type f \) -exec echo {} \; -exec rm -rf {} \; > /volume1/95_wartung/delete_temporary_files.sh.$(date +%Y-%m-%d).log

 

[dil88]

Für mich macht das, was Du schreibst, sehr viel Sinn. ".DS_Store" ist eine (unsichtbare) Mac-Systemdatei, die vermutlich einen ähnlichen Zweck hat, wie Daten in den @eaDir-Verzeichnissen. Es ist völlig logisch, dass diese Informationen auf der DS in @eaDir und nicht in ".DS_Store" landen, weil ersteres die DSM-Struktur ist und letzteres nicht.

Da ACL-Rechte in den @eaDir-Metadaten gespeichert werden, macht es ebenfalls Sinn, dass der Zugriff aus Windows heraus, das ebenfalls mit ACL arbeitet, nicht klappt, wenn die Rechteinformationen fehlen.

Nun könnte man zwar sagen ist nicht so wild, einfach eaDir nicht löschen. ABER: Das Problem ist insbesondere dann kritisch, wenn von einer bestehenden Umgebung auf ein NAS migriert wird. Dann sind diese eaDir Informationen (je nach Vorgehen) nämlich nicht gesetzt und docx-Dateien unter Win8.1 (vermute mal bei älteren auch) erstmal nicht zugreifbar.

Hast Du das getestet oder vermutest Du es? Ich kann es mir nämlich nicht vorstellen, weil die ACL-Rechteinformation in den @eaDir-Verzeichnissen ja sofort geschrieben werden müssen, damit die DS ihre Funktion erfüllen kann. Sprich: Zum Anlegen einer Datei gehört automatisch, dass die Rechteinformation geschrieben wird. Das sollte eigentlich einwandfrei funktionieren.

 

[mama-YT]

Hast Du das getestet oder vermutest Du es?

Ich habe es vermutet, was aber falsch war. Wenn man die Dateien mittels SMB transferiert werden die automatisch angelegt (habe es soeben mittels einem Backup geprüft). Das ist jetzt natürlich etwas bitter, da die eaDir Ordner natürlich überall fehlen. Sie wiederherzustellen wäre in diesem Umfang zu aufwändig.

Was das Problem jedoch löst (ohne MacUser):
1. In Verzeichnis @eaDir des Ordners der betroffenen DOCX Datei wechseln
2. Via shell "touch [Dateiname]@SynoResource"

Dann ist sie wieder zugreifbar.

Das Problem scheint aufzutreten, wenn alle folgenden Faktoren zutreffen:

• DOCX-Datei (oder es war mal eine, umbenennen hilft nicht, Dateien im gleichen Ordner mit anderer Endung gehen jedoch)
• Besitzer ist ein anderer Benutzer (darf aber gleiche Gruppe sein)
• @eaDir/[dateiname]@synoResource existiert nicht

Selten tritt der Fall auf, dass eine Datei trotz all dieser Bedingungen zugreifbar ist. Habe noch nicht rausgefunden woran das dann liegt.