Ordnerstrukturen auf Aktualisierung prüfen

[__blackjack__]

Problem beim sofortigem weiterverarbeiten ist bei so ziemlich allen Ansätzen dieser Art, dass man nicht wirklich robust feststellen kann wann eine Datei fertig geschrieben oder verändert ist.

Ansonsten kann man natürlich auch noch den Metainformationen glauben schenken und muss nur in Verzeichnisse abtauchen die verändert worden sind.

[Karlirex]

Problem beim sofortigem weiterverarbeiten ist bei so ziemlich allen Ansätzen dieser Art, dass man nicht wirklich robust feststellen kann wann eine Datei fertig geschrieben oder verändert ist.

Ansonsten kann man natürlich auch noch den Metainformationen glauben schenken und muss nur in Verzeichnisse abtauchen die verändert worden sind.

Gibt es denn da Ansätze, die sinnvoller/besser lösbar sind?

[sparrow]

@Karlirex:

Indem man eine Kovention findet, die zeigt, dass die Datei fertig geschrieben ist.

beio (S)FTP-Verbindungen macht man das zum Beispiel gerne so, dass man wartet bis der schreibende Client sich wieder auslogt. Dann geht man davon aus, dass der Schreibvorgang wohl durch sein sollte.
Da wartet man also auf ein Event, das signalisiert, dass sich etwas geändert hat.

Üblich ist auch den Schreibvorgang in eine Datei gar nicht in die (bereits vorhandene) Zieldatei vorzunehmen sondern in eine andere temporäre Datei in dem selben Verzeichnis zu schreiben, der per Konvention einen anderen Dateinamen zu geben. Am Ende des Schreibvorganges wird dann die eigentliche Zieldatei umbenannt, die neu geschriebene in die Zieldatei umbenannt und anschließend die alte Datei gelöscht.
Insbesondere MS-Office macht das so IIRC.
Wenn also die geänderte/neue Datei die temporäre Datei ist, kann man die ignorieren. Und mit der Umbenennung ist die neue Datei sofort da.

Wenn du von einem "FileServer" sprichst, meinst du dann eigentlich, dass das eine eingebundene Netzwerkfreigabe ist? Wenn ja: Welches Protokoll und welche beteiligten Betriebssysteme?
Denn je nachdem ist das für dein Vorhaben füchterlich unperformant (insbesondere bei SMB/Windows) (was auch die ewigen Laufzeiten erklärt) und du kannst das mit den Notifications aus dem System für Änderungen möglicherweise vergessen.

[Karlirex]

@sparrow:
Achherrje, da habe ich scheinbar die Büchse der Pandora geöffnet.

Aber ist das mit dem Neuschreiben der Dateien nicht nochmal deutlich langsamer? Klingt für mich gerade so, als wäre mein Vorhaben eine Aufgabe die sich pro Durchlauf für 1-2h ausklinkt

Ich verbinde mit mit dem Skript ja ausschließlich über die Pfade.
Soweit ich das weiß, handelt es sich um einen Windows-Fileserver, Linux(?) gibts bei uns noch nicht sonderlich lange.

[__deets__]

Nein, wenn in eine neue Datei schreiben per se langsamer waere, und erst recht deutlich, dann haettest du das ganz sicher schon bemerkt. Oder "recycelst" du auch bestehende Dokumente und Dateien?

Der Grund fuer das neu schreiben liegt in dem atomaren Vorgang der Umbenennung. Das ist halt viel robuster, weil man bei Fehlern beim schreiben der Datei die alte nicht verliert. Und der Moment des umbenennens kurz, und deutlich robuster ist.

[Karlirex]

@_deets_: ich denke nicht.
Ich habe nur noch nicht so ganz eine Vorstellung davon, wie ich das Umsetzen soll, vorallem, da ich den "Wachschritt" ja dennoch brauche oder?
Deshalb auch der Gedanke, dass es dann langsamer ist. Ich muss ja beobachten um eine Datei, die neu ist, zu erfassen. Und das Beobachten dauert ja aktuell wie gesagt ca. 400s.

Oder ich habs noch nicht ganz verstanden...

[sparrow]

@Karlilex: Wieso schreibst du Dateien? Ich denke, du suchst nur nach geänderten Dateien?

Die Frage nach dem Networkshare hast du leider unbeantwortet gelassen.

[Karlirex]

@Karlirex:

Indem man eine Kovention findet, die zeigt, dass die Datei fertig geschrieben ist.

beio (S)FTP-Verbindungen macht man das zum Beispiel gerne so, dass man wartet bis der schreibende Client sich wieder auslogt. Dann geht man davon aus, dass der Schreibvorgang wohl durch sein sollte.
Da wartet man also auf ein Event, das signalisiert, dass sich etwas geändert hat.

Üblich ist auch den Schreibvorgang in eine Datei gar nicht in die (bereits vorhandene) Zieldatei vorzunehmen sondern in eine andere temporäre Datei in dem selben Verzeichnis zu schreiben, der per Konvention einen anderen Dateinamen zu geben. Am Ende des Schreibvorganges wird dann die eigentliche Zieldatei umbenannt, die neu geschriebene in die Zieldatei umbenannt und anschließend die alte Datei gelöscht.
Insbesondere MS-Office macht das so IIRC.
Wenn also die geänderte/neue Datei die temporäre Datei ist, kann man die ignorieren. Und mit der Umbenennung ist die neue Datei sofort da.

Klingt für mich als würde eine Datei geschrieben werden.

Wenn du von einem "FileServer" sprichst, meinst du dann eigentlich, dass das eine eingebundene Netzwerkfreigabe ist? Wenn ja: Welches Protokoll und welche beteiligten Betriebssysteme?
Denn je nachdem ist das für dein Vorhaben füchterlich unperformant (insbesondere bei SMB/Windows) (was auch die ewigen Laufzeiten erklärt) und du kannst das mit den Notifications aus dem System für Änderungen möglicherweise vergessen.

Wenn die Antwort nicht der Windowsserver ist, dann kann ich dir dazu leider nichts sagen.


Nochmal generell, es soll der gesamte Server überwacht werden, mit dem bin ich per Netzwerklaufwerk verbunden. (F:\) diesen Pfad gebe ich ein und dann lasse ich das Monitoring laufen.
Im weiteren Schritt sollen dann nicht nur die neuen/geänderten Dateien erkannt werden sondern diese dann auch "bearbeitet/verarbeitet" werden. (Daher auch nochmal hier der Gednake für Schreiben.

[sparrow]

Wer ändert die Dateien auf dem Server?
Schreibst du selber mit dem Script auch in das Verzeichnis? Wenn ja: Wie stellst du sicher, dass die Dateien, die das Script verändert hat, nicht noch einmal durch das Script verarbeitet werden?

[Karlirex]

Wer ändert die Dateien auf dem Server?
Schreibst du selber mit dem Script auch in das Verzeichnis? Wenn ja: Wie stellst du sicher, dass die Dateien, die das Script verändert hat, nicht noch einmal durch das Script verarbeitet werden?

Das was überwacht werden soll, wird vom Menschen dort geschrieben bzw. abgelegt. Dieses Ablegen möchte ich mit dem Skript wahrnehmen und dann die meisten Daten ggf. verarbeiten, da dort vieles Messdaten sind. Das Weitervearbeiten wird dann eben vom Skript gemacht (bspw. Plotten/Excel/CSV-Dateien schreiben).

[sparrow]

Ach man, es ist ein bisschen anstrengend, wenn man immer nur die Hälfte seiner Fragen beantwortet bekommt.
Schreibt dein Script auch in das überwachte Verzeichnis?

[Karlirex]

Ach man, es ist ein bisschen anstrengend, wenn man immer nur die Hälfte seiner Fragen beantwortet bekommt.
Schreibt dein Script auch in das überwachte Verzeichnis?

Das oben genannte Skript und die bisher gezeigten Idee (in den Codetags) schreiben doch offensichtlich nicht in irgendein Verzeichnis oder?
Da es sich bei dem überwachten Verzeichnis um einen großen übergeordneten FileServer handelt, wie schon erwähnt, sollen logischerweise die dann später geschriebenen Dateien auch auf dem Fileserver landen. Tendenziell in einen "bearbeitet-Datei" Ordner, wie das dann aussehen soll, kann ich aber noch nicht genau sagen. (Ist es so ungewöhnlich, dass man einen FileServer überwacht und dann wieder Daten daraufgeschrieben werden, statt auf einen zweiten?(es handelt sich ja hier nicht um irgendeine Backup-Idee)

*es kann aber auch sein, dass eine Datei mit dem selben Namen nochmal hinzugefügt wird, welche dann aber neueren Inhalt enthält. Daher die Idee mit der mtime-Funktion, da doch so das nicht beibehalten würde.

[sparrow]

Irgendwie liest du meine Beiträge immer nur halb.
Es ist nicht ungewöhnlich dort hin zu schreiben. Die Frage war ob du bedacht hast, dass dein Script dann auch wieder Dateien ändert.

Statt deines bisherigen Vorgehens da auf gut Glück minutenlang Verzeichnisbäume zu scannen, würde ich versuchen die hier bereits benannten Events des Betriebssystems zu nutzen.

Schnapp dir das von imonbln bereits angesprochene watchdog und guck, ob das die passenden Events produziert. Ich kenne Fälle, da hat das von Client auf einer Netzwerkfreigabe funktioniert - und ich kenne Fällt da hat es nicht funktioniert.
Wenn es nicht funktioniert hat, dann hat es immer dann nicht funktioniert, wenn nicht der Client, auf dem der Watchdog läuft, die Datei erstellt oder ändert. Das scheint aber seit ein paar Windows-Versionen zu funktionieren.

Die Events würde ich mir anschauen - speziell die "modified"-Events. Damit weißt du, welche Datei gerade geändert wurde. Quasi in Echtzeit.
Das Problem: Es gibt kein "die Datei wurde fertig geschrieben"-Event. Das heißt, du weißt, dass die Datei gerade geändert wurde - aber du weißt nicht, ob die Änderung bereits abgeschlossen ist. Wenn du da eine große Datei hin kopierst, wirst du bemerken, dass ständig modified-Events kommen, die irgendwann aufhören.
Und mit "anschauen" meine ich, dass du das laufen lassen sollst.
Das Test-Script in der Dokumentation ist ja sehr übersichtlich und die Einrichtung dauert ein paar Minuten.

Wenn die Events wie gewünscht kommen: Merk dir, wann das letzte Event für eine Datei kam. Wenn das x Zeit her ist, verarbeite die Datei.

Das würde ich versuchen, bevor ich stundenlang Verzeichnisse durchsuche um Änderungen möglichst zeitnah zu erfassen.

Und ja, dein Script muss dann natürlich laufen, damit es Änderungen erfährt. Kein Script, keine verarbeiteten Events.
Deshalb ist es eigentlich sinvoll, dass das Script auf dem Server direkt läuft.
Sollte das auf dem Client laufen und der potentiell nicht laufen, müsstest du dann über ein Fallback über den Verzeichnisscan nachdenken um die in er Zwischenzeit geänderten Dateien zu sehen.

Zumindest habe ich deine Häppchen-Informationen so verstanden, dass du die Dateien möglichst sofort weiterverarbeiten willst und dafür ständig das Verzeichnis scannst.

[grubenfox]

Üblich ist auch den Schreibvorgang in eine Datei gar nicht in die (bereits vorhandene) Zieldatei vorzunehmen sondern in eine andere temporäre Datei in dem selben Verzeichnis zu schreiben, der per Konvention einen anderen Dateinamen zu geben. Am Ende des Schreibvorganges wird dann die eigentliche Zieldatei umbenannt, die neu geschriebene in die Zieldatei umbenannt und anschließend die alte Datei gelöscht.

Was die temporäre Datei betrifft: z.B. ein Dateiname der mit einem Punkt beginnt und erst wenn die Datei fertig geschrieben ist wird der Dateiname mit Punkt in den Namen ohne Punkt geändert. Unter Linux/Unix sind Dateinamen die mit Punkt beginnen per Definiton unsichtbar und wenn sich das lesende Programm auch daran hält dann werden eben die temp. Dateien mit Punkt am Anfang des Namens nicht beachtet bis der Punkt da weg ist.

[__blackjack__]

@grubenfox: Habe ich so in der Praxis aber noch nirgends gesehen, weil das den Nachteil hat, dass da dann eventuell grosse und/oder viele *versteckte* Dateileichen liegen bleiben. Und das funktioniert auch nicht systemübergreifend. Was ich dagegen schon öfter gesehen habe ist eine zusätzliche Dateiendung wie `.part` für die noch nicht kompletten Dateien.

[grubenfox]

@grubenfox: Habe ich so in der Praxis aber noch nirgends gesehen, weil das den Nachteil hat, dass da dann eventuell grosse und/oder viele *versteckte* Dateileichen liegen bleiben. Und das funktioniert auch nicht systemübergreifend. Was ich dagegen schon öfter gesehen habe ist eine zusätzliche Dateiendung wie `.part` für die noch nicht kompletten Dateien.

Da wüsste ich hier mehrere Handvoll Server die das so handhaben und es läuft gut... (eigentlich sind es noch mehr Systeme, aber die anderen sind mir alle nicht explizit bekannt.) und bei den Servern auf der einen Seite der Übertragung auf die ich meistens Zugriff habe, sind mir noch keine Dateileichen aufgefallen.
Sind aber alles Windows-Server. Ich glaube die zeigen auch Dateien mit Punkt im Dateiexplorer kann. Wegen Urlaub habe ich nun gerade keinen Zugriff und kann das daher nicht überprüfen.

Wobei "groß": eher nicht eigentlich ein- oder unterer zweistelliger Kilobyte-Bereich. "viele": wie gesagt, hier noch nicht aufgefallen.

[__deets__]

rsync macht das auch genau so.