Script ausführen, wenn neue Dateien/Ordner in Ordner kommen?

[mensa]

Hallo,

ist es möglich, dass ein Script gestartet wird, sobald jemand neue Dateien/Ordner in einen bestimmten "überwachten" Ordner kopiert?
Ziel wäre es, dass Dateien und Ordner, welche z.B. *sample* beinhalten sofort gelöscht werden.

Oder geht das nur mit einem Cronjob, der einfach jede Minute läuft? Aber das ist vermutlich nicht so optimal für die Festplatten, wenn jede Minute ein find Befehl über einen Ordner mit knapp 2 TB und 300 Dateien in knapp 100 Ordnern läuft, oder?

 

[Uwe96]

Reicht es nicht wenn man das einmal die Woche macht?

 

[mensa]

Nein, bei weitem nicht. Sollte wirklich on-the-fly passieren, oder alle paar Minuten.

 

[frimp]

Nein so leicht geht das nicht. Die stetige Überwachung geht nur sinnvoll auf inode-Ebene. Soweit ich weiss unterstützt der Linux-Kernel von Synology kein inotify direkt.
Auf der anderen Seite müsste synoindex genau so etwas machen.
Ich meine es gab mal ein französisches Repository mit den inotify-tools, vielleicht gibt es das noch...

 

[mensa]

Ich habs jetzt mal so gelöst in einem Script und es funktioniert wie gewünscht, weiß aber nicht ob das so zu empfehlen ist. Was ist eure Meinung hierzu?

- Script läuft per cronjob jede Minute und liest per "ls" die Größe des Ordners /volume1/share/Downloads aus und speichert diese.

- Wenn sich beim nächsten Aufruf die Größe des Ordners vom vorigen Aufruf unterscheidet, weiß ich, dass Dateien/Ordner hinzugekommen sind oder gelöscht wurden und das Script löscht die ungewünschte Dateien und Ordner per find.

Läuft eigentlich wie gewünscht und find wird auch wirklich nur bei Veränderungen im Ordner aufgerufen. Was halt minütlich passiert ist ein "ls -l /volume1/share/ | grep -w "Downloads" | awk '{print $5}'".

Ist das auf Dauer unproblematisch, oder würdet ihr es anders lösen?

 

[TeXniXo]

einen Ordner mit knapp 2 TB und 300 Dateien in knapp 100 Ordnern läuft, oder?

Nun ja, wenn in dieser eine Minute die Ordner in diesem Ausmaß gelöscht werden soll (wird ganz sicher nicht innerhalb 1 Minute fertig sein, wenn es um 2 TBs geht), wird schon der nächste Befehl aufgerufen und der erkennt natürlich die Veränderungen (da ja grad die Dateien gelöscht werden) und ruft dann die gliechen Zeilen auf und sie löschen dann ... und .. was kommt dann? ERORR

Ich würde das Ganze mal auf 15 Minuten stellen oder eben weitere Zeilen reinfügen, dass das Script erst ausgeführt wird, wenn die Ordnergröße <100 KB ist?

 

[ruedi66]

Eine bessere Idee habe ich auch gerade nicht zur Hand wenn die Dateien schon vorhanden sind.
Aber wieso entstehen die *sample* Dateien. Wenn du Sie von einem Archiv entpackst, dann kannst du im 7z z.B. einen Filter einbauen, damit sie erst gar nicht entpackt werden.

 

[mensa]

Die Dateien/Ordner *sample*, *.jpg, etc. sind oft in Downloads enthalten und ungewünscht, da diese die App Infuse am Apple TV durcheinander bringen und oft dazu führen, dass der Film nicht korrekt erkannt wird.
Ich weiß, dass man im JDownloader beim Archiventpacker gleich mit regulären Ausdrücken bestimmte Dateien/Ordner ausschließen lassen könnte, das möchte ich aber nicht, da das dann ja für alle Downloads gelten würde. Mein aktuelles find Script läuft pro Ordner nur, wenn sich in diesem eine *.mkv oder *.iso befindet.

Nun ja, wenn in dieser eine Minute die Ordner in diesem Ausmaß gelöscht werden soll

Es steht nirgends, dass der Ordner in diesem Ausmaß gelöscht werden soll.

 

[NSFH]

Warum machst du das so kompliziert? Ein Cronjob, der alle 5 Minuten bestimmte Datetypen in einem Ordner löscht reicht doch. Wenn nichts zum löschen da ist passiert auch nichts. Warum vorher prüfen, ob sich was verändert hat.

 

[mensa]

Weil ich eben Bedenken habe, wenn da dauernd ohne Grund ein find Befehl über alle Downloads drüberlaufen muss. Vermutlich mach mir da eh ohne Grund sorgen?
Oder ist das doch berechtigt? Deshalb frage ich ja nach eurer Meinung hier.

Mir ist schon klar, dass nichts passiert. Find läuft aber trotzdem dauernd und das frisst schon halbwegs Ressourcen (glaube ich mal gelesen zu haben).

 

[NSFH]

Den Aufwand kannst du vernachlässigen. Ich habe auf den Servern zum Teil mehr als 10 Cronjobs für unterschiedlichste Dinge laufen. Dieser Löschbefehl ist ein kleiner Peak in der Auslastung, da du damit keine Mengen oder riesige Dateien entfernst.
Ich führe auf gleiche Art auf einer 916+ auch Copyjobs durch, davon merkt man gar nichts. Kannst ja auch das Zeitfenster vergrössern, je Stunde sollte für sowas doch reichen.

 

[TeXniXo]

Kannst ja auch das Zeitfenster vergrössern, je Stunde sollte für sowas doch reichen.

War ja auch ein Vorschlag von uns ...
Offensichtlich nicht, denn

Nein, bei weitem nicht. Sollte wirklich on-the-fly passieren, oder alle paar Minuten.

ist ja absolut und klar verständlich, ne?

 

[PsychoHH]

Dann nutzt man einfach find -mtime oder -mmin

 

[mensa]

Dann nutzt man einfach find -mtime oder -mmin

Dann müsste aber sichergestellt sein, dass das Script jede Minute zuvor korrekt durchgelaufen ist, denn sonst entgeht einem damit ja was.

 

[ruedi66]

Das könntest du mit einem Lookfile und if [ $? -eq 0] nach dem find lösen

 

[mensa]

Was ist ein Lookfile?

 

[ruedi66]

Sorry, Lockfile. Damit kannst du das Script blockieren, damit es nicht 2 mal gleichzeitig läuft

 

[mensa]

Danke, aber das sehe ich gar nicht als Problem.
Ich sehe eher dieses Problem: Wenn ich mit find -mmin arbeite und jede Minute nur die Ordner/Files prüfe, welche nicht älter als 1 Minute ist, dann geht mir alles durch die Lappen, wenn das Script mal aus irgendeinem Grund nicht gelaufen sein sollte. Oder wie hättest du das gelöst?

 

[PsychoHH]

Da inotify so nicht funktioniert, musst du dir halt etwas bauen. Entweder cron oder Endlosschleife.

 

[framp]

Nein so leicht geht das nicht. Die stetige Überwachung geht nur sinnvoll auf inode-Ebene. Soweit ich weiss unterstützt der Linux-Kernel von Synology kein inotify direkt.
Auf der anderen Seite müsste synoindex genau so etwas machen.
Ich meine es gab mal ein französisches Repository mit den inotify-tools, vielleicht gibt es das noch...

Bist Du sicher? Hast Du mal inotifywait ausprobiert? Hast Du einen Link auf das frz Repo?