Sync bei der Dateiverwaltung - unerwartet 2100 Dateien gelöscht

[Piet]

(Homepage von 2009; auf Version 4.10.5 hochgezogen; lief mit 4.10.5 nun einige Monate)

Ich habe es wieder mal geschafft. Ich muss auf ein Backup zurückgreifen.
Warum? Ja warum? Ich verstehe es nicht.

In der Dateiverwaltung gibt es Dateien und zugehörige Metadaten und irgendwelche Hashes.

Der Sync sollte, meiner Meinung nach da sein, um diese zusammenzuführen.

Gerade gemacht und siehe da:

>>>

Dateien
Die Synchronisation wurde abgeschlossen

Zurück
Ergebnis: 10 neu | 121 geändert | 2.490 unverändert | 0 verschoben | 2.101 gelöscht Unveränderte anzeigen

>>>

Jetzt versuche ich Infos zum Sync zu bekommen, finde im Handbuch aber nichts.
Zwar wird die Dateiverwaltung beschrieben, aber den Sync finde ich nicht.

Wie kommt der Sync dazu ganze Ordner und Bilddateien von über 10 Jahren zu löschen?

Einige wurden dazugefügt (aufgenommen in die DB-Verwaltung?)
Viele wurden gelöscht (sieht nach Bildern aus dem News-Bereich aus)


:-( Der Sync fragt nicht mal, ob er löschen darf.

Wer hat den Sync verstanden? Wer kann ihn erklären? Eine Idee warum es bei mir die genannten Auswirkungen hatte?


Piet

[Spooky]

"Gelöscht" heißt hier: aus der Datenbank gelöscht, weil die Dateien nicht mehr da sind. Der Sync an sich löscht keine physischen Dateien.

[mlweb]

(Homepage von 2009; auf Version 4.10.5 hochgezogen; lief mit 4.10.5 nun einige Monate)

Unabhängig von Deinem aktuellen Problem - wieso hast Du auf Contao 4.10 aktualisiert. Contao 4.10 wird doch schon seit Februar 2021 nicht mehr supported - das sind dann schon deutlich mehr als einige Monate.

[Piet]

Unabhängig von Deinem aktuellen Problem - wieso hast Du auf Contao 4.10 aktualisiert. Contao 4.10 wird doch schon seit Februar 2021 nicht mehr supported - das sind dann schon deutlich mehr als einige Monate.

Na ja - auch 15 Monate sind Monate und Ich hatte 2018 von 2.x auf 3.5, dann Jan 2021 auf 4.10 und nun auf 4.13 upgedated.

Und abgesehen davon, habe ich mit zu großen Versionssprüngen bei Updates schlechte Erfahrungen.

Alte Systeme immer schön über die LTS-Versionen und dann die letzte Version der Versionsreihe hochziehen.

Typolight habe ich nun keine Installationen mehr, außer ein alter Kunde wärmt die wieder auf.

2.x auf 2.lts auf 2.last dann zu 3.lts, dann zu 3.last, dann ....

Das hat sich bisher bewährt.

Oder machst Du das anders?

[Piet]

"Gelöscht" heißt hier: aus der Datenbank gelöscht, weil die Dateien nicht mehr da sind. Der Sync an sich löscht keine physischen Dateien.

Puh richtig, die Dateien sind noch da, ABER in der Homepage fehlen sie dennoch:

Schon auf der Startseite herrscht Chaos:
Sync-Vergleich.jpg

Ich muss am Wochenende mal feststellen, ob es eine Regel gibt, warum einige noch da sind und andere weg sind.

Verstehst Du den Sync? Kannst Du mir mal einen Tipp geben, wo ich suchen muss?

Piet

NACHTRAG, EDIT

Erste Vermutung: alles vor einem Stichtag scheint weg zu sein. Neueres aus den letzten Jahren scheint noch da zu sein.
Vielleicht alles vor 3.x oder vor 4.x ??? Einsatzbilder aus 2009 bis 2020 sind z. B. weg; ab Jan 2021 sind die Bilder noch da.
Das war der Umstieg auf die 4er Versionsreihe.

[tab]

Hattest du schon alle Dateien in der neuen Installation, als das erste Mal das Installtool aufgerufen wurde? Falls nicht, werden die noch fehlenden Dateien beim Sync aus der Datenbank entfernt. Werden sie dann erst später wieder hinzugefügt, kommen sie zwar in die Datenbank, aber mit einer anderen UUID als sie ursprünglich hatten. Da die Zuordnung von Bildern/Dateien zu Inhaltselementen usw aber über die UUID läuft, steht in den Inhaltselementen eben die ursprüngliche UUID drin. Die gibt es dann aber nicht mehr in der Datenbank, deswegen wird das Bild nicht angezeigt. Der Sync sorgt halt immer dafür, dass die Datenbank auf den Stand des Dateisystems gebracht wird. Deswegen ist es unerlässlich, dass das Installtool erst aufgerufen wird, wenn alle Bilder in die neue Installation übertragen sind und möglichst auch in die selben Verzeichnisse wie zuvor! Was ich mir auch noch vorstellen könnte ist, dass ein Teil der Dateien eventuell bei der Übertragung verändert wurden, z.B. wenn sie per FTP nicht im Binärmodus übertragen wurden.

[Piet]

Frag mich bitte nicht in welcher Reihenfolge damals der Umstieg auf 4.10 bei dieser Homepage ablief.

Sie tat.

Doch nun zum Sync:

Wenn ich es richtig verstanden habe, dann

• Wird jedem Bild bei der Benutzung eine UUID zugewiesen
• Diese UUID ist dann quasi der Schlüssel in einer DB-Tabelle auf den wirklichen Dateinamen
• In den Artikeln, News, ... steht dann nur die UUID

Richtig?


Da also bisher alles tat, war in der DB unter der richtigen UUID der richtige Dateinamen abgelegt. - oder ???

Der Sync prüft nun, ob die Dateien noch dort auf dem Server auf der Platte sind. ???

Wenn er die Datei zu diesem Zeitpunkt nicht findet / nicht sieht, dann löscht er den DB Eintrag und die UUID im Artikel zeigt in die Sterne??? Richtig??

Wie kann man nun die Referenztabelle UUID zu Dateinamen "reparieren"? Warum wurde sie ungültig?


Viele Fragen, aber noch eine: Wo liegt der Hund begraben? :-)


Piet

[tab]

Frag mich bitte nicht in welcher Reihenfolge damals der Umstieg auf 4.10 bei dieser Homepage ablief.

Sie tat.

Doch nun zum Sync:

Wenn ich es richtig verstanden habe, dann

• Wird jedem Bild bei der Benutzung eine UUID zugewiesen
• Diese UUID ist dann quasi der Schlüssel in einer DB-Tabelle auf den wirklichen Dateinamen
• In den Artikeln, News, ... steht dann nur die UUID

Richtig?

Ja, allerdings wird die UUID nicht erst bei Benutzung der Datei zugewiesen, sondern schon dann, wenn sie über den Dateiupload im Backend hochgeladen wird. Bei FTP-Upload dann eben beim nächsten Sync. Da wird sie dann als neu gefunden und in die DB aufgenommen, wobei ihr dann auch ihre UUID zugeordnet wird. Solange sie nicht in der DB (tl_files) steht, kann sie zumindest über den Dateipicker nicht in einem Inhaltselement ausgewählt werden. Aber natürlich wäre es möglich sie trotzdem manuell, z.B. in einem Text oder HTML-Element, als Bild zu verlinken.

Da also bisher alles tat, war in der DB unter der richtigen UUID der richtige Dateinamen abgelegt. - oder ???

Ja.

Der Sync prüft nun, ob die Dateien noch dort auf dem Server auf der Platte sind. ???

Wenn er die Datei zu diesem Zeitpunkt nicht findet / nicht sieht, dann löscht er den DB Eintrag und die UUID im Artikel zeigt in die Sterne??? Richtig??

Richtig. Es ist aber noch etwas komplexer. Wenn er die Datei nicht an der erwarteten Stelle im Dateisystem findet aber dafür an einer anderen Stelle (Die Datei wird dabei anhand des Hashwerts identifiziert), dann geht er davon aus, dass es die selbe Datei ist, die vom alten Ort an den neuen verschoben wurde. In diesem Fall bleibt der Eintrag inklusive UUID erhalten, aber der alte Pfad wird durch den neuen ersetzt. Somit funktioniert die Zuordnung weiterhin korrekt, obwohl die Datei verschoben wurde. Es gibt auch noch ein paar weitere Feinheiten, die ich jetzt ohne ansehen des Codes nicht mehr weiss. Insbesondere, was genau passiert, wenn man die bestehende Datei per FTP mit einer neuen überschreibt, also mit dem selben Dateinamen, und keinen Sync durchführt. Sie wird dann zwar überall korrekt angezeigt, aber wenn man dann diese geänderte Datei per FTP verschiebt, kann das nicht mehr nachvollzogen werden, da der Hashwert der gefundenen, veränderten und verschobenen Datei nicht zum in der DB eingetragenen Hash (immer noch der der alten Datei) passt. Das System ist also nicht 100% fail safe, insbesondere wenn Dateien per FTP geändert und/oder verschoben werden und danach kein Sync durchgeführt wird.

Wie kann man nun die Referenztabelle UUID zu Dateinamen "reparieren"? Warum wurde sie ungültig?

Sie zu reparieren ohne die ursprüngliche Zuordnungen zu kennen, geht meines Wissens nicht. Wenn du von der funktionierenden 4.10 Installation ein Datenbank-Backup hast, kannst du das einspielen. Um das ganze Zusammenspiel ein wenig besser zu verstehen, die Zuordnung findet über die Tabelle tl_files statt. Da steht drin, welche Datei momentan wo im Dateisystem liegt (relativ zu /files), welche UUID sie hat und welchen Hashwert.

Hier könnte eventuell auch ein älteres Backup der Datenbank helfen, die ursprünglichen UUIDs der damals schon bestehenden Dateien in der aktuellen DB zu restaurieren. Aber das ist dann schon eine ziemliche Friemelei, kann gutgehen oder auch nicht.

Viele Fragen, aber noch eine: Wo liegt der Hund begraben? :-)

Ehrlich gesagt, keine Ahnung. Irgendwann etwas getan, was man besser nicht getan hätte oder vergessen zu tun, was man hätte tun sollen. Dass es bis zum Sync funktioniert hat, kann ich mir momentan nicht erklären, zumal ja beim letzten Update in jedem Fall auch schon ein Sync durchgeführt wurde, jedenfalls sofern das Installtool aufgerufen wurde.

[mlweb]

Oder machst Du das anders?

Ich arbeite bei Kunden zu 90% mit der LTS-Version. Wenn ich mich entscheide - aus welchem Grund auch immer - eine Nicht-LTS-Version einzusetzen, weiß ich von vornherein, dass ich längstens nach 6 Monaten ein Update machen muss und das weiß dann auch mein Kunde.

Die 4.10 war keine LTS-Version.

Meine Bemerkung bezog sich aber vor allem darauf, dass ich angenommen habe, dass Du die ganze Zeit in einer 4.10 arbeitest, ein Backup eingespielt hast, dann die Dateiverwaltung synchronisiert hast und dabei Probleme aufgetreten sind.

Mit welcher Contao-Version gab es den das Problem nach der Synchronisation der Dateiverwaltung, bei einer Synchronisation in Contao 4.10 oder nach dem Update auf Contao 4.13?

Richtig. Es ist aber noch etwas komplexer. Wenn er die Datei nicht an der erwarteten Stelle im Dateisystem findet aber dafür an einer anderen Stelle (Die Datei wird dabei anhand des Hashwerts identifiziert), dann geht er davon aus, dass es die selbe Datei ist, die vom alten Ort an den neuen verschoben wurde. In diesem Fall bleibt der Eintrag inklusive UUID erhalten, aber der alte Pfad wird durch den neuen ersetzt. Somit funktioniert die Zuordnung weiterhin korrekt, obwohl die Datei verschoben wurde. Es gibt auch noch ein paar weitere Feinheiten, die ich jetzt ohne ansehen des Codes nicht mehr weiss. Insbesondere, was genau passiert, wenn man die bestehende Datei per FTP mit einer neuen überschreibt, also mit dem selben Dateinamen, und keinen Sync durchführt. Sie wird dann zwar überall korrekt angezeigt, aber wenn man dann diese geänderte Datei per FTP verschiebt, kann das nicht mehr nachvollzogen werden, da der Hashwert der gefundenen, veränderten und verschobenen Datei nicht zum in der DB eingetragenen Hash (immer noch der der alten Datei) passt. Das System ist also nicht 100% fail safe, insbesondere wenn Dateien per FTP geändert und/oder verschoben werden und danach kein Sync durchgeführt wird.

M.E. funktioniert Verschieben per FTP grundsätzlich nicht. Überschreiben per FTP mit dem gleichen Dateinamen und nachträgliches Verschieben in der Dateiverwaltung war bei mir bewusst noch kein Problem unabhängig davon, ob ich die Dateiverwaltung synchronisiert habe oder nicht. Damit gehe ich nämlich immer etwas nachlässig um, bisher Gott sei Dank ohne Folgen.

Wie kann man nun die Referenztabelle UUID zu Dateinamen "reparieren"? Warum wurde sie ungültig?

Ich glaube auch, dass ein händischen Reparieren der DB schwierig, aufwendig und fehleranfällig ist. Händisch neu zuordnen ist auch nicht gerade prickeln wenn man viele Bilder hat.

Hast Du nach der Synchronisation der Dateiverwaltung mal den Server- und den Browser-Cache geleert?

Wenn es nicht am Cache liegt, würde ich über eine Parallelinstallation mit Contao 4.13 gehen.
Dazu grob gesagt folgende Schritte durchführen:

• neue DB anlegen
• Backup einer funktionierenden DB importieren
• eine Subdomain für die Parallelinstallation anlegen
• Parallelinstallation mit allen erforderlichen Erweiterungen installieren
• alle eigenen Dateien (Files, Templates, Konfigurationsdateien ggf. individuelle oder manuell installierte Erweiterungen) in die Parallelinstallation kopieren
• die neue Installation mit der neuen DB verbinden und alle Datenbankmigrationen ausführen lassen
• neue, migrierte DB für alle Fälle sichern
• Backend aufrufen und notwendige Files-Ordner auf "öffentlich" stellen
• Frontend anschauen und mit Glück freuen, dass fast alles funktioniert - kommt halt auf das Theme, die verwendeten Erweiterungen und angepassten Templates an
• Templateanpassungen bei angepassten Templates mit dem Original vergleichen und ggf. anpassen
• Synchronisation in der Dateiverwaltung durchführen
• wenn alles passt Domain auf diese neue Installation rooten
• Subdomain auf alte Domain rooten - das hat den Vorteil, dass Du auch noch später nachschauen kannst (Frontend und Backend) wie etwas in der alten Installation aussah/gelöst war, falls einem etwas komisch vorkommt
• alte Installation dann nach einiger Zeit nicht vergessen zu löschen

[Piet]

Mit welcher Contao-Version gab es den das Problem nach der Synchronisation der Dateiverwaltung, bei einer Synchronisation in Contao 4.10 oder nach dem Update auf Contao 4.13?

Es handelt sich um die 4.10.5. Wie gesagt, sie lief nun schon über 1 Jahr.
Eigentlich gab es gar keinen wirklichen Grund für den Sync, denn ich war NUR im falschen Backend.

[Piet]

Hast Du nach der Synchronisation der Dateiverwaltung mal den Server- und den Browser-Cache geleert?

Ja habe ich nun mal bewusst durchgeführt. Die Bilder sind in der Darstellung weg.

Ich überlege gerade, was ein erneuter Sync für Auswirkungen hätte.
@tab
Ein erneuter Sync würde nun allen Bildern, die er auf der Platte findet eine neue UUID geben.
Diese korreliert aber nicht mit der UUID in den Artikeln bzw. News.

Diese UUIDs sind aber noch in den Artikeln und News gespeichert - oder?

Wenn ich nun alte tl_files-DB mit neuer tl_files-DB per Programm vergleiche,
könnte ich eine Referenztabelle zwischen den beiden herstellen.
Aber wie könnte ich in den Artikeln / News die UUIDs in der DB ersetzen?

Quatsch - vergiss es - ich nehme das Backup und blende den "Sync" im Backend aus. Never touch it again.

(Hoffentlich brauche ich ihn dann nie.)

ODER wird der irgendwo automatisch aufgerufen (z.B. Install, ...)???

[Piet]

Status - bisher keine Erklärung - Lösung über eingespieltes BackUp - Sync tut nicht

Der Reihe nach:

Ich hatte vermutet, dass es vielleicht ein "Aussetzer" beim Webserver war.
Dass genau zum Zeitpunkt des Sync ein Zugriff auf Dateien nicht möglich war.

Also habe ich die Tabelle tl_files aus einer Sicherung heraus wieder hergestellt.
Und siehe da, alle Bilder waren wieder an ihrem Platz.


Dann habe ich den Sync nochmals gestartet und die gleichen Ergebnisse erhalten.
Auch wieder wurden 2101 Dateieinträge gelöscht.
Also keine Unzulänglichkeit oder Unpässlichkeit des Servers.

Zur Verdeutlichung hier Teile der Ausgabe des Syncs:
Screenshot 2022-04-09 100820.jpg

und viele Zeilen später:

Screenshot 2022-04-09 100943.jpg



Rund 220 mal wurde ein Hashwert erneuert.
Und dann 2101 Zeilen aus der DB gelöscht.
Übrigens:
Es sind 4712 Zeilen in der Tabelle vor dem Sync
Danach sind es 2621. Die Anzeige des Syncs stimmt zumindest. (10 neue, 2101 gelöscht)

Ich kann den Sync nicht mehr nutzen.

IDEEN????



Ich habe die gleiche Installation nach einem Update nun auch nochmal unter 4.13 laufen.
Ich werde auch dort (NACH einer Sicherung) mal den Sync anstossen. Ich erwarte die gleichen Resultate.

Vielleicht .... aber ... bin einfach gespannt

[tab]

Langsam gehen mir die Ideen aus. Eventuell mal in die Datenbanktabelle tl_files schauen, den Eintrag eines Bilds suchen, das nach dem Sync nicht mehr funktioniert und alles notieren, Hash UUID, Dateiname, am besten alles. Dann Sync durchführen, wieder den Eintrag der selben Datei anschauen und die Werte vergleichen. Man muss erst einmal herausfinden, was nicht passt, vielleicht findet sich dann eine Möglichkeit, so viel wie möglich wieder herzustellen.

[mlweb]

Ich denke ich würde mir mal ein Bild, was nach dem Sync verschwunden ist heraussuchen und merken.
Das Backup wieder einspielen, dieses Bild im Backend neu zuordnen und dann den Sync erneut durchführen.

Wenn dann dieses Bild erhalten bleibt, sind wohl die gelöschten Zuordnungen nie richtig in der DB angekommen. Dann kann man vielleicht gezielt suchen warum oder ob man das irgendwie elegant beheben kann oder man geht den Fleiß-Weg und ordnet die Bilder neu zu.
Bei Dir sind das ja zum Teil Galerien, wenn ich das richtig gesehen habe. Da geht das bei geschicktem Aufbau der Ordnerstruktur in der Dateiverwaltung relativ zügig.
Es ist zwar trotzdem eine stupide Arbeit, aber was solls.

Ich habe so etwas ähnliches gerade in einer Installation durch, die ich neu übernommen habe. Dort waren alle Galerien entweder in den Tiny gekloppt oder auch mal in HTML-Elementen verbaut. Ist eine Scheissarbeit, aber machbar.

[Piet]

Langsam gehen mir die Ideen aus. Eventuell mal in die Datenbanktabelle tl_files schauen, den Eintrag eines Bilds suchen, das nach dem Sync nicht mehr funktioniert und alles notieren, Hash UUID, Dateiname, am besten alles. Dann Sync durchführen, wieder den Eintrag der selben Datei anschauen und die Werte vergleichen. Man muss erst einmal herausfinden, was nicht passt, vielleicht findet sich dann eine Möglichkeit, so viel wie möglich wieder herzustellen.

Ich habe einen Hinweis:

Es sieht so aus, als ob alle Dateieintrage rausfliegen, die als Namenserweiterung ".JPG" haben.
".jpg" kleingeschrieben bleibt drin.
Die Dateien haben laut Filezilla aber alle keine großgeschriebene Namenserweiterung.
Es gibt sie also nicht wirklich. Stehen aber definitiv AUCH mit großem JPG in der Datenbank drin.

Und da nach dem Sync viele Bilder auf der Homepage fehlen, scheint mindestens eine Vorversion von Contao mit großen "JPGs" gearbeitet zu haben.
Denn diese UUIDs sind wohl in den Artikeln und News hinterlegt. Dabei bitte nicht vergessen, dass der Ursprung der Homepage von 2009 ist, da hieß es noch Typolight.


INSERT INTO `tl_files-zerst` (`id`, `pid`, `tstamp`, `uuid`, `type`, `path`, `extension`, `hash`, `found`, `name`, `meta`, `importantPartX`, `importantPartY`, `importantPartWidth`, `importantPartHeight`) VALUES

Hier wird es wichtig

aus OK: 4 mal das gleiche Foto (namentlich) in "NOCH OK"
(1375, 0xa069ab78767911e9add1525400234cf5, 1557860087, 0xbec8afeb767911e9add1525400234cf5, 'file', 'files/tl_files/fw-ek/dat/Einsatzfotos/2019/05-2019/2019-05-14 F2G Unterschelmerath01.JPG', 'jpg', '285802b0c856f6cc0a18d13f7b1fb7cc', '1', '2019-05-14 F2G Unterschelmerath01.JPG', NULL, 0, 0, 0, 0),
(1682, 0x662f06f3de4111e99390525400234cf5, 1569270808, 0x663ef426de4111e99390525400234cf5, 'file', 'files/tl_files/fw-ek/dat/2019/05-2019/2019-05-14 F2G Unterschelmerath01.JPG', 'jpg', '285802b0c856f6cc0a18d13f7b1fb7cc', '1', '2019-05-14 F2G Unterschelmerath01.JPG', NULL, 0, 0, 0, 0),
(3612, 0x313e71ff649d11ebb193525400049142, 1612191186, 0x313e71a4649d11ebb193525400049142, 'file', 'files/tl_files/fw-ek/dat/Einsatzfotos/2019/05-2019/2019-05-14 F2G Unterschelmerath01.jpg', 'jpg', '35c60b866e1021f7f26f0d75a1c51da4', '1', '2019-05-14 F2G Unterschelmerath01.jpg', NULL, 0, 0, 0, 0),
(4271, 0x35614194649d11ebb193525400049142, 1612191193, 0x356140dd649d11ebb193525400049142, 'file', 'files/tl_files/fw-ek/dat/2019/2019/05-2019/2019-05-14 F2G Unterschelmerath01.jpg', 'jpg', 'a9969750094e6de4d52d5871642d7292', '1', '2019-05-14 F2G Unterschelmerath01.jpg', NULL, 0, 0, 0, 0),

davon übrig "NACH SYNC"
(3612, 0x313e71ff649d11ebb193525400049142, 1612191186, 0x313e71a4649d11ebb193525400049142, 'file', 'files/tl_files/fw-ek/dat/Einsatzfotos/2019/05-2019/2019-05-14 F2G Unterschelmerath01.jpg', 'jpg', '35c60b866e1021f7f26f0d75a1c51da4', '1', '2019-05-14 F2G Unterschelmerath01.jpg', NULL, 0, 0, 0, 0),
(4271, 0x35614194649d11ebb193525400049142, 1612191193, 0x356140dd649d11ebb193525400049142, 'file', 'files/tl_files/fw-ek/dat/2019/2019/05-2019/2019-05-14 F2G Unterschelmerath01.jpg', 'jpg', 'a9969750094e6de4d52d5871642d7292', '1', '2019-05-14 F2G Unterschelmerath01.jpg', NULL, 0, 0, 0, 0),



Nachtrag, Ergänzung

Je länger ich nachdenke, desto eher verfalle ich dem Gedanken, dass nicht der Sync den Fehler gemacht hat, sondern die Umgebung des Contao-Systems.
Könnte also der Webserver, dessen Konfiguration, die PHP-Umgebung plötzlich anders sein, dass es nun beim Sync zu diesen Problemen kommt.

Lösung wäre natürlich nun, dass das System die KLein-gross-Schreibung beim Sync nicht mehr beachtet. Damit wären alle Dateien noch vorhanden und der Sync würde notwendige Einträge und UUIDs nicht löschen.
Aber macht das der Sync oder der Read auf die Datei?

Ideen?

[tab]

Offenbar sind zumindest zum großen Teil die Dateien .mit dem großen ".JPG" die "richtigen", benötigten Dateien. Denn wenn die gelöscht sind (in der Datenbanktabelle tl_files), werden die Bilder nicht mehr angezeigt. Ob das überall so ist, müsstest du halt noch bei neueren Dateien überprüfen. Existieren denn die verschiedenen Namensvarianten auch alle am in der DB angegebenen Ort auf der Festplatte, also nicht nur in der DB? Falls nicht, ist das Dateisystem des aktuellen Servers eventuell case insensitiv? Kann man leicht testen, indem man etwa eine existierende Datei beispiel.jpg nach beispiel.JPG kopiert. Sind hiernach beide Dateien vorhanden, ist das Dateisystem case sensitiv, ansonsten eben nicht. Deine Datenbank scheint ja beide Varianten deiner Dateien zu enthalten - vor dem Sync. Aber sind auch beide Varianten auf der Festplatte vorhanden?

Wie es entstanden sein kann? Ich bin da jetzt auch nicht unbedingt der Experte, aber es wäre für mich zunächst einmal denkbar, dass das Problem durch einen Wechsel von case sensitiven und insensitiven Zeichensätzen bzw auch Datenbankkollationen irgendwann im Lauf der Jahrzehnte , naja, da es jetzt erst auftritt wahrscheinlich eher kürzlich, entstanden ist. Manche Server sind case sensitiv, manche case insensitiv. Ebenso kann man Datenbanken auf beide Weisen einstellen. Welche Kollation haben denn deine Datenbanktabellen, insbesondere tl_files?