Hi Rocco, danke für Deine Antwort, hatte in meiner ersten Mail aber schon geschrieben:
"Ich würde daher gerne vorher überprüfen, ob ein anderer Prozess grade an der Datei schreibt. Leider hat File kein Attribut um das filelock ab zu fragen, sondern nur eine Methode um es zu setzen... Hatte schon überlegt bei jedem Durchgang des Loop zu schauen, ob sich die Größe der Datei verändert hat, aber ich habe gehofft, dass es da evtl. einen saubereren Weg gibt." Hi Rene, das ganze wird erstmal im LAN laufen, deswegen wäre (erstmal) SMB bzw. AFP das Mittel der Wahl. Der Gedanke mit einer Art Hook auf fertige Uploads in Samba bzw Netatalk zu arbeiten ist mir noch nicht gekommen, weiß allerdings nicht, ob diese das unterstützen (werde ich gleich nachschauen). Danke für die Idee! Was meinst Du mit dem letzten schreibenden Zugriff auf eine Datei? Meinst Du die Überprüfung, wie lange die letzte Änderung der Datei her ist? - Wenn diese älter als N Sekunden ist, ist an zu nehmen, dass die Datei fertig hochgeladen wurde. In der Art? Grüße Matthias On 06.12.2009, at 13:28, Rocco Di Leo wrote: > Hi, > > lass den Daemon doch einfach mehrmals - z.B. alle paar Sekunden - die > Dateigröße neuer Uploads überprüfen bevor du sie weiterverarbeitest. Wenn > sich die Dateigröße zwischen den Prüfungen ändert, steht diese noch im > aktiven Uploadprozess, wenn nicht, dann ist die Datei wahrscheinlich komplett > hochgeladen worden (oder es gab einen Abbruch beim Client) - so oder so kann > die Datei aus der Dropbox gefischt und weiter verarbeitet werden. > > Grüße > Rocco > > 2009/12/6 Matthias Lindhorst <matthias.lindho...@alternativeblue.com> > > Am 6. Dezember 2009 01:29 schrieb Matthias Lindhorst > > <matthias.lindho...@alternativeblue.com>: > >> > >> Hallo Liste, > >> > >> schlage mich seit einigen Tagen mit einem Problem herum und sehe einfach > >> kein Land. > >> > >> Zur Situation: > >> Ich habe einen kleinen Daemon in meine Rails app integriert, der ein > >> Folder, dass als Dropbox dient, auf neue Dateieingänge überwachen soll. > >> Ist eine Datei eingegangen, soll diese in ein temporäres Verzeichnis > >> geschoben werden, auf das der User erstmal keinen Zugriff hat. > >> > >> Nun stehe ich vor folgendem Problem: > >> Kopiere ich zum Beispiel über das Netzwerk eine große Datei in die Dropbox > >> macht sich der Daemon fröhlich daran diese zu verschieben, obwohl sie noch > >> gar nicht vollständig ist. > > > > Hallo Matthias, > > > > wenn Du den Upload-Prozess selbst im Griff hast, wäre es das beste, > > die Dateien erst nach dem vollständigen Upload so umzubenennen, dass > > der Daemon sich dann dafür zuständig fühlt. Falls die Dateiinhalte > > bestimmten Kriterien genügen müssen (oder es sogar ein von Dir > > definiertes Dateiformat ist), wäre es sicher möglich anhand dieser > > Kriterien (Checksumme, EOF-Markierung o.ä.) zu entscheiden, ob die > > Datei vollständig ist. > > > > Viele Grüße, > > Martin > > > > P.S.: Filelocks werden Dich hier nicht weiter bringen. > > > > -- > > GL Networks > > Martin Rehfeld > > martin.rehf...@glnetworks.de > > www.glnetworks.de > > _______________________________________________ > > rubyonrails-ug mailing list > > rubyonrails-ug@headflash.com > > http://mailman.headflash.com/listinfo/rubyonrails-ug > > Hallo Martin, > > danke für Deine Antwort. > Ich habe den Upload - Prozess nicht selbst im Griff - und das ist ja genau > mein Problem. > Das ganze Projekt ist ein Prototyp für eine auf Rails basierende, > serverseitige Medienverwaltung. > Die Rails app soll zum Beispiel auf dem Fileserver laufen. Auf die Shares für > Musik usw. soll per SMB, AFP o.Ä. nur lesend zugegriffen werden können. > Um neue Musikstücke oder Filme in das System zu bringen, wird nach aussen > eine Dropbox angeboten, auf die nur schreibend zugegriffen werden kann. > Damit ich die eingespielten Files in der Datenbank verzeichnen und > Metainformationen auslesen kann, müssen diese aber vollständig hochgeladen > sein. > Ein Upload via HTTP, bringt mich nicht wirklich weiter, weil er entweder > unkomfortabel ist (kein Upload ganzer Ordner), oder über flash, etc. > realisiert werden müsste. > > Grüße > Matthias > > _______________________________________________ > rubyonrails-ug mailing list > rubyonrails-ug@headflash.com > http://mailman.headflash.com/listinfo/rubyonrails-ug > > _______________________________________________ > rubyonrails-ug mailing list > rubyonrails-ug@headflash.com > http://mailman.headflash.com/listinfo/rubyonrails-ug
_______________________________________________ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
