[4.1.8] Dateianhänge werden nicht gelöscht

  • Affected App
    WoltLab Suite Forum

    Anscheinend gibt es auch ohne das Tapatalk-Plugin noch ein Problem mit Dateianhängen, welche unter bestimmten Umständen nicht gelöscht werden. Die Deails hier im Einzelnen:


    1. Wenn innerhalb eines Threads ein neuer Beitrag erstellt und ein Dateianhang hochgeladen wird, der Beitrag jedoch nicht beendet wird und man stattdessen wieder zur Startseite zurückkehrt, bleibt der Dateianhang verwaist auf dem Server zurück. Versucht man den Beitrag im selben Thread fort zu setzen, wird nur der Text selbst wieder hergestellt, nicht jedoch der Dateianhang. Man kann diesen zwar neu hochladen, doch bleiben die alten Dateien im System zurück und werden anscheinend auch nicht durch den Cronjob "Löscht verwaiste Dateianhänge" gelöscht (getestet mit manueller Durchführung: "Cronjob jetzt ausführen"). Oder wird dieser Cronjob erst nach einer bestimmten Zeit aktiv?


    2. Sollte ein zeitversetzer Beitrag mit einem Dateianhang, welcher im Originalformat in den Beitrag eingefügt wird vor der Veröffentlichung nochmals ediert und dieser dann nach der Veröffentlichung gelöscht werden, verbleibt sowohl der Dateianhang als auch das Vorschaubild unter "Inhalt > Dateianhänge" im System. Versucht man diesen im ACP zu löschen, ist dies nicht mehr möglich. Man sieht nur noch eine dauerhafte Sanduhr. Die einzige Möglichkeit ist das manuelle Löschen der Dateien im Verzeichnis "wcf/attachments/ordner/" sowie das Entfernen der letzten Einträge aus der Datenbank-Tabelle "wcf1_attachment". Das Problem trat mehrfach beim Erstellen einer erweiterten Antwort auf und sollte sich bei jedem reproduzieren lassen.

  • 1. Wenn innerhalb eines Threads ein neuer Beitrag erstellt und ein Dateianhang hochgeladen wird, der Beitrag jedoch nicht beendet wird und man stattdessen wieder zur Startseite zurückkehrt, bleibt der Dateianhang verwaist auf dem Server zurück

    Wo hast du den Dateianhang auf dem Server explizit gefunden und lässt sich bei, angenommen es würden 100 oder mehr Dateien "zurück bleiben", jeder Dateianhang einem Benutzer zuordnen?

  • Ja, es gibt zu jedem Dateianhang eine User-ID. Allerdings werden die Dateinamen verschlüsselt so das sie auf dem Server nicht denselben Namen haben wie die original hochgeladenen Datei bzw. wie sie im Beitrag dargestellt wird. Man kann die entsprechenden Dateien nur ausfindig machen, indem man die ID-Nummern aus der Tabelle "wcf1_attachment" mit den Dateianhang-ID's im ACP vergleicht und ID's ausfindig macht, die im ACP nicht mehr zu finden ist (bezogen auf Punkt 1). Insgesamt ein ziemlich aufwändiges Verfahren. Hat man eine ID in der Tabelle entdeckt, die im ACP unter den Dateianhängen nicht mehr zu finden ist, kann man mit einem Dateimanager wie dem "Total Commander" die entsprechenden Dateien mit dem "fileHash"-Wert ausfindig machen, d.h. man kopiert die lange ID, welche in etwa so aussieht "620mljznf1f1364c73n73js4dbb92c52acbfd34099" in die TC-Suchfunktion (Alt + F7) und kann die gefundenen Dateien danach löschen. Allerdings kann das doch eigentlich nicht Sinn und Zweck der Sache sein.


    Update: Gerade festgestellt, das es über die User ID auch einfacher geht, die entsprechenden Dateien ausfindig zu machen, sofern Derjenige nicht so viele Dateien hochgeladen hat (ansonsten ist auch hier die Sortierung chaotisch). Trotzdem sollten solche verwaisten Dateien doch eigentlich vom Forum selbst bzw. vom Cronjob gelöscht werden.

    Edited 4 times, last by PARALAX ().

  • Nein, es ging mir um die physikalische Datei die "angeblich" zurück geblieben ist, laut deinem Vorwurf. Was in der Datenbank ("MySQL") steht/nicht steht, ist dabei erst einmal unerheblich. Mir kommt es leider so vor, als würdest du krampfhaft etwas versuchen zu konstruieren das sich nicht lohnt einen Gedanken zu verschwenden. Egal ob ein Eintrag in der Datenbank zurück bleibt - solange kein offensichtliche Fehlermeldung kommt kann es dir doch egal sein ob da Dateinamen in der Datenbank zurück bleiben. Wenn eine Datei verworfen wird landet sie eigentlich (so viel ich weiß) in einem Temp-Ordner oder Cache der in bestimmten Abständen vom System gelöscht wird. Von daher mach doch bitte kein Fass wegen so was auf. ;)

  • Es geht mir nicht um Einträge in der Datenbank sondern um die Tatsache das unter bestimmten Umständen alte Dateianhänge auf dem Server verbleiben, die keinen Beiträgen oder PN's mehr zugeordnet sind, was ein eindeutiger Fehler ist, weil die Dateien eigentlich von selbst gelöscht werden sollten, wenn sie nicht zugeordnet werden können. Wenn Jeder User hingehen und seine Beiträge trotz hochgeladener Dateien nicht beenden würde und Dinge ausgeführt werden wie in Punkt 2 beschrieben, dann stauen sich da schnell einige MB zusammen, die nie wieder genutzt werden. Und da es keine globale Speicherverwaltung bzw. ein entsprechendes Limit gibt, ist das schon eine Sache, die man nicht herunter spielen sollte.

    • Official Post

    Hallo,


    die verwaisten Anhänge werden erst nach frühstens 24 Stunden gelöscht, andernfalls ist es zu wahrscheinlich, dass der Anhang verschwindet, während der Nutzer noch an Beitrag schreibt.

  • Hallo,


    die verwaisten Anhänge werden erst nach frühstens 24 Stunden gelöscht, andernfalls ist es zu wahrscheinlich, dass der Anhang verschwindet, während der Nutzer noch an Beitrag schreibt.


    Danke, das wollte ich nur wissen. Habe mir nur erlaubt darauf hin zu weisen, falls es noch Niemanden aufgefallen sein sollte und es ein Fehler hätte sein können. Werde mir das aber morgen Abend nochmal anschauen. Anscheinend betrifft es nämlich auch alle Dateianhänge, die über PN's verschickt werden. Wird ein User einer Konversation im Forum gelöscht, der die Dateianhänge noch im Postfach hatte, verbleiben die Dateien nämlich ebenfalls auf dem Server, auch wenn die Konversation vom Absender bereits verlassen wurde.

  • Oder wird dieser Cronjob erst nach einer bestimmten Zeit aktiv?


    die verwaisten Anhänge werden erst nach frühstens 24 Stunden gelöscht,


    Das hätte Dir ein Blick in die Cronjob-Klasasendatei auch verraten.





    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier.

  • Der steht nach wie vor unverändert auf "Stunde 2", also "Nächste Ausführung: 3:00 Uhr Morgens". Allerdings sollte der Job trotzdem sofort ausgeführt werden wenn man den entsprechenden Play-Button ganz links drückt. Dies bewirkt allerdings nicht die manuelle Löschung der besagten Dateien. Deswegen war ja meine Frage, ob es da noch einen anderen Timer gibt, bevor der Cronjob überhaupt aktiv wird.

    • Official Post

    Der steht nach wie vor unverändert auf "Stunde 2", also 3:00 Uhr morgens. Allerdings sollte der Job trotzdem sofort ausgeführt werden wenn man den entsprechenden Play-Button ganz links drückt. Dies bewirkt allerdings nicht die manuelle Löschung der besagten Dateien. Deswegen war ja meine Frage, ob es da noch einen anderen Timer gibt, bevor der Cronjob überhaupt aktiv wird.

    Die Ausführungszeit hat keinen Einfluss auf die tatsächliche Durchführung, denn wenn die Ausführung für 3 Uhr geplant ist und ein Benutzer anfängt einen Beitrag mit Anhang um 2:59 Uhr zu schreiben, darf der Cronjob 1 Minute diesen Dateianhang löschen. Im Cronjob selbst wird bei allen in Frage kommenden Anhängen das Datum des Uploads geprüft.

  • Ich schrieb "in die Klassendatei" und nicht "Protokoll/Auflistung der Cronjobs".


    Code: AttachmentCleanUpCronjob.class
    (TIME_NOW - 86400)




    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier.

  • Habe das ganze nun nochmal getestet. Zu diesem Zweck hatte ich die verwaisten Dateien vorgestern kopiert, um zu sehen ob sie heute noch auf dem Server liegen. Eigentlich hätten die entsprechenden Dateien um 3:00 Uhr gelöscht werden müssen - wurden sie aber nicht! Auch das manuelle Löschen brachte keinen Erfolg. Somit scheint es wohl doch ein Fehler zu sein, denn die entsprechenden Schreibrechte waren im Ordner vorhanden und der Cronjob wurde angeblich auch ordnungsgemäß ausgeführt. Allerdings kann ich mir absolut nicht erklären, wieso das keine Wirkung zeigte.


    Im Cronjob selbst wird bei allen in Frage kommenden Anhängen das Datum des Uploads geprüft.


    Das Datum der betroffenen Dateien war der 8.12.2015 um 10:25. Somit hätten die Dateien am 10.12.2015 um 3:00 Uhr gelöscht werden müssen, was sie aber nicht wurden. Zudem ist in der Datenbank-Tabelle "wcf1_attachment" bei der entsprechenden Anhangs-ID immernoch der Wert "NULL" im Feld "userID" eingetragen, welcher auf den gelöschten User verweist, dessen Dateien noch im Posteingang waren. Irgendwas kann da also nicht stimmen. Falls sich das Jemand von euch mal konkret anschauen möchte, könnte ich nach Absprache eine entsprechenden Zugang dafür bereit stellen.

    Edited 4 times, last by PARALAX ().

  • Meist weil man zu viel in Sachen rumfummelt wo man nicht sollte :) oder hunderte von Addons draufhat die alle Schuld sein könnten...

  • Ich habe keine unoffiziellen Addons installiert, die damit was zu tun haben könnten. Das kann ich soweit versichern!

  • Ich habe im Moment ein Backup des Forums auf einem anderen Server zu Testzwecken eingespielt und sämtliche Plugins deinstalliert - mit demselben Ergebnis. Die betroffenen Dateien werden nicht gelöscht! Interessanterweise bekomme ich im Gegensatz zu Firefox beim Opera-Browser im ACP eine Fehlermeldung angezeigt wenn ich versuche die Dateianhänge, welche unter bestimmten Umständen unter "Inhalt > Dateianhänge > Dateianhänge verwalten" nicht gelöscht werden können.


    Code
    Fatal error: Call to a member function getModeratorPermission() on a non-object in /www/htdocs/ordner/board/lib/data/thread/Thread.class.php on line 135


    Beim Firefox dagegen wird einfach nur eine dauerhafte Sanduhr angezeigt und nichts geschieht. Damit ich das ganze in Echtzeitbedingungen testen kann habe ich den Inhalt der entsprechenden Cronjob-Datei angepasst:


    Code: AttachmentCleanUpCronjob.class
    (TIME_NOW - 0)

    Was ich zumindest schonmal bestätigen kann ist, das das Löschen von hochgeladenen Dateien funktioniert, wenn man den Thread verlässt und auf die Startseite geht. Kommt es dagegen zum o.g. Sonderfall mit geplanten Beiträgen & Edieren so das auch intern über das ACP die entsprechenden Dateianhänge nicht gelöscht werden können, funktioniert das ganze nicht mehr. Des Weiteren werden auch keine Dateianhänge innerhalb von Konversationen gelöscht, wenn Useraccounts entfernt wurden. Ich werde das ganze jetzt nochmals mit einer Neuinstallation testen und versuchen den Fehler erneut mit geplanten Beiträgen zu reproduzieren. Danach schicke ich euch die entsprechenden Zugangsdaten zu.

  • Des Weiteren werden auch keine Dateianhänge innerhalb von Konversationen gelöscht, wenn Useraccounts entfernt wurden.


    Das ist vollkommen korrekt, da die Konversation selbst noch existiert.

  • Das ist vollkommen korrekt, da die Konversation selbst noch existiert.


    Nicht aber wenn sie vom Absender verlassen wurde und der Empfänger nicht mehr existiert. Dieser Fall wurde von mir getestet und führte nicht zur Löschung der entsprechenden Dateien.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!