Jede Menge corrupter Dateien bei Typolight-Check!

Ich habe mal nach längerem wieder den Check laufen lassen, da die Kommentarfunktion bei mir nicht funktioniert.

Nun habe ich festgestellt, dass TC jede Menge an corrupter Dateien bemängelt.
http://s10b.directupload.net/images/...p/cu2udcs3.png

Ich habe beide Archive, sowohl .tar.gz und zip getrennt neu geladen und auch getrennt entpackt. Damit versucht die corrupten Dateien zu ändern. Unterschiedliche Übertragungstools verwendet.
Die Meldungen bleiben aber bestehen. :(

Kann das Jemand bestätigen, dann schreibe ich ein Ticket für leo!

Schau mal da -> https://community.contao.org/de/show...4&postcount=31

Eventuell hilft das weiter.

Viele Grüße

Hmmm, danke!

Allerdings habe ich bis zum Update auf 2.8 damit garkeine Probleme gehabt, zumal das Update über Live-ID eingespielt wurde.

Obendrein stehen alle FTP-Tools auf automatische Erkennung der Dateien.
Geändert habe ich sie auch nicht auf dem Rechner, sodass ich vielleicht falsch gespeichert hätte. :(

Edit:
Ich habe ja auch schon andere Dateien ändern können.
Von daher dürfte das nicht zutreffen. :(

Naja, das feature, das es getestet wird obs corrupt ist oder nicht, ist ja erst seit dem typolight-check.php für die 2.8 dabei.
Komisch es es dann schon wenns über die live-update-ID gekommen ist, könnten aber auch die Dateien sein, die du am Anfang hochgeladen hattest.
Schlimm ist die Übertragung in nem anderen Modus ja auch nicht vom Ergebniss, da die Inhalte im Grunde noch gleich sind. Aber dann passiert sowas eben bei ner automatischen Überprüfung.

Also Teste doch mal einfach anhand von ein paar Dateien die du einfach noch mal hochlädst. Wenn sich dann der Status positiv ändert weißt du ja wo du drann bist.

Viele Grüße

Nein, kann ich nicht bestätigen. Das Check Tool funktioniert einwandfrei:

http://contifex.com/typolight-check.php

(Was da rot ist sind Dateien die ich bewusst gelöscht, resp. wegen laufender Entwicklung geändert habe)

Versichere dich, dass dein FTP-Upload "Binär" erfolgt.

Genau das habe ich probiert!
Es waren ja auch nicht die einzigen Dateien, die das Tool bemängelte.
Die anderen habe ich auch beheben können und das waren einige, diese Überreste leider nicht. :(

Ich werde dann wohl Leo mal anhauen, dass vielleicht die Archive defekt sein könn ten.

Kannst du denn mal schauen was an den bemängelten Dateien nicht stimmen soll?
Eventuell hat auch dein FTP-Prog bzw. der Server probs beim hochladen von so vielen Dateien? Da gibts ja den ein oder anderen Hoster, der da für timeouts sorgt o.ä.

Wäre also Hilfreich wenn du mal genauer gucken könntest und vllt auch etwas genauer beschreiben.

Was hast du zum beispiel gemacht, damit ein paar Fehler weggekommen sind?

Ne, Timeouts sind es nicht!

Scheinbar haben WinSCP und FlashFXP beide Probleme mit der automatischen Erkennung für binäre Übertragung.

Ich habe WinSCP jetzt mal auf binäre Übertragung umgestellt, mal sehen was da passiert.

Jedenfalls konnte ich die langconfig.php wohl so ändern. :)

Ich habe auf ena-webstudio.com ebenfalls via LiveUpdate das Update der 2.8 drüber gezogen und bekomme für viele Files die corrupt-Meldung.

Es handelt sich vor allem um die tinyMCE-Files sowie noch um folgende Dateien:

HTML-Code:

---

system/modules/frontend/templates/ce_accordion_stop.tpl
system/modules/frontend/templates/ce_headline.tpl
system/modules/frontend/templates/ce_html.tpl
system/modules/frontend/templates/mod_html.tpl
system/modules/frontend/templates/search_default.tpl
typolight/page.php

---

Die Frage ist halt, ob das schon bei der letzten Version so war (habe ich per FTP hochgeladen) oder erst bei dieser (via LiveUpdate).

Zitat:

---

Zitat von Thomas

Obendrein stehen alle FTP-Tools auf automatische Erkennung der Dateien.

---

Genau das klingt für mich nach NICHT binär, d.h. dein FTP Programm darf nach eigenem Gutdünken mal binär und mal im Textmode übermitteln.

So viele waren es bei mir dann doch nicht!
Ist ja beängstigend. :(

Zitat:

---

Genau das klingt für mich nach NICHT binär, d.h. dein FTP Programm darf nach eigenem Gutdünken mal binär und mal im Textmode übermitteln.

---

Das nehme ich auch an!
Ob das jetzt Überreste von der 2.7.6 ist kann ich nicht mehr sagen, aber wie gesagt, trotz Live-Update.

Ich mache mal ein manuelles Update dieser Files aus dem ZIP-Paket.

Alle Meldungen weg!

Ich war auch immer im Glauben, dass binär für doc, exe usw. genommen wird.

Aber wieder etwas dazu gelernt.

Danke Euch.

Ich meine irgendwo gelesen zu haben dass der Live-Update die Copyright-Header nicht mehr berücksichtigt oder übermittelt. Damit wird der Systemcheck natürlich dann ausgehebelt weil die Dateigrössen nicht mehr übereinstimmen würden.

P.S. Apropos binär vs. Textmode:

Das definiert nur ob das FTP Programm eine Konvertierung des Zeilenabschlusses bei Textdateien vornehmen soll oder nicht. Da sämtliche Webserver aber mit UNIX- wie auch mit Windows-Textdateien umgehen können sollte man immer Binär übermitteln damit die Dateien genau so ankommen wie sie abgeschickt werden.

Dann ist mit Sicherheit die falsche Übertragung schon unter 2.7.6 vorhanden gewesen.

Meine Probleme mit der Kommentarfunktion sind dennoch nicht behoben.

Zitat:

---

Zitat von Thomas

Ich war auch immer im Glauben, dass binär für doc, exe usw. genommen wird.

---

Ich hatte dazu definitiv auch ein Missverständnis. Habe deswegen ein wenig nachgelesen und dazu gelernt.

Dazu das Zitat eines englischen Posts aus dem Webmasterworld-Forum:

Zitat:

---

Every byte is 8 bits. In ASCII, a byte is made up of 7 "significant" bits and an eighth, "insignificant" bit, used for error control. Binary uses all 8 bits as significant bits. Text-only is ASCII, whereas word processing documents, image and data files, etc, are binary.

If a binary file is transferred in ASCII mode, every eighth bit becomes corrupted and the file unusable — you inevitably corrupt a binary file by sending it as ASCII.

But sending ASCII files as binary works much of the time, if the operating systems on both ends are using the same convention for that eighth "error-checking" bit. However, you certainly CAN get into trouble with Unix/Mac/Windows mismatches which use different conventions.

So, a javascript file, being a text-only or 7 bit file, will usually transfer just fine in either mode. But it is most properly ASCII, as far as I know. This is also true for HTML files.

---

und noch

Zitat:

---

You're partially correct about using the 8th bit as error control, however, it's outdated. The eighth bit can also be used for internationalization (extended character sets or codepages) but there is no standard for this.

The main use of ASCII transfer in FTP is for the FTP server to strip line ending characters (carriage return and line feeds) into the correct form for the server: on *NIX boxes, a CR/LF pair will be converted into a single LF. (MS-DOS/Windows computers use Carriage Return/Line Feed pairs to denote the end of a line)

All files are binary, ASCII is just a subset. It would be less confusing if instead of ASCII mode, the FTP clients called it 'text mode'. So if you sent an 8 bit ASCII file via FTP, any 8th bit that is set would be retained, and any CR/LF pairs would be converted to a single LF.

---

Man man man.. und die ganze Aufregung obwohl ich das direkt gesagt habe ;-)

Also binär solls sein, damit /r/n noch /r/n bleibt und nicht zu /n wird was dann die größe der Dateien abändert.

Genaueres kann euch da eventuell Xtra sagen. Wir hatten das Thema nur schon mal besprochen im Chat ;-)

Ich finde sowas sollte durchaus in den FAQ Bereich von TL.

Viele Grüße

Hab die korrupten Files via FTP mit frischen Files überspielt und nun ist alles fein. Ich vermute mal, dass diese Files vom LiveUpdate gar nicht betroffen waren, sondern von mir schon zuvor bei einem FTP-Upload dummerweise nicht binär hochgeladen wurden.

Tja, man lernt nie aus. :)

Unter Umständen sogar als deutlich gemachter Hinweis in der Installationsanweisung.
Wer kommt schon auf sowas, wenn man Jahre Lang automatisch übertragen hat. :(

Ich hab es mal als Kommentar in der englischen/deutschen Install-Anleitung dazu geschrieben. Leo wird das dann ggf. direkt in die Anleitung übernehmen oder halt so als Kommentar drunter stehen lassen.

Ich glaube nicht, dass es an den Zeilenvorschüben liegt, denn der Systemcheck erkennt unterschiedliche Formate und entfernt Carriage Returns automatisch für die Prüfung. Allerdings gibt es FTP-Programme, die im Ascii-Modus auch den Zeichensatz prüfen bzw. ändern. Kann es eventuell daran liegen?

Zitat:

---

Zitat von acenes

Nein, kann ich nicht bestätigen. Das Check Tool funktioniert einwandfrei:

http://contifex.com/typolight-check.php

(Was da rot ist sind Dateien die ich bewusst gelöscht, resp. wegen laufender Entwicklung geändert habe)

Versichere dich, dass dein FTP-Upload "Binär" erfolgt.

---

Das war bei mir ein definitiver Punkt in WinSCP...im tinyMCE-plugin wurden auch nach frischem Neu-Upload Files angemeckert, erst "binär" (ohne Autoerkennung!) löste das Problem...

Stefan

Zitat:

---

Zitat von leo

Ich glaube nicht, dass es an den Zeilenvorschüben liegt, denn der Systemcheck erkennt unterschiedliche Formate und entfernt Carriage Returns automatisch für die Prüfung. Allerdings gibt es FTP-Programme, die im Ascii-Modus auch den Zeichensatz prüfen bzw. ändern. Kann es eventuell daran liegen?

---

Du hast bedacht, dass es 3 verschiedene Zeilenumbryche gibt? Das wird mir naemlich in meinen Entwicklungen auch immer mal wieder zum Verhaengnis.
Windows: \r\n
Unix: \n
Macintosh(vor OSX): \r

Faktum ist jedoch, dass man zur Sicherheit die Daten im BINARY Mode ybertragen sollte, damit sie genau so, wie sie vom Hersteller (Leo) ausgeliefert werden, auch auf dem Server landen.
WinSCP und FlashFXP wandeln btw. nur die Line endings um (\r\n => \n und anschliessend \r => \n).
Im Check mysste man diese alle entfernen.

@Leo: Weitere Frage am Rande, wie verhaelt es sich mit Tabs und Spaces, welche den codeflow nicht beeinflussen jedoch auch unterschiedlich sein koennten? Ignorierst du die in deinem Check auch (Hab mir den Source noch nicht angesehen)? Wenn nein, waere evtl. eine Idee diese ebenfalls zu strippen.

Ich glaube ich muss das Problem bei mir mal nachstellen und dann reinsehen wo genau der mismatch auftritt.

Zitat:

---

Zitat von xtra

Du hast bedacht, dass es 3 verschiedene Zeilenumbryche gibt? Das wird mir naemlich in meinen Entwicklungen auch immer mal wieder zum Verhaengnis.

---

Es werden alle \r entfernt, insofern sollte es daran nicht liegen.

Zitat:

---

Zitat von xtra

@Leo: Weitere Frage am Rande, wie verhaelt es sich mit Tabs und Spaces, welche den codeflow nicht beeinflussen jedoch auch unterschiedlich sein koennten?

---

Daran könnte es tatsächlich liegen. Aber gibt es wirklich FTP-Programme, die beim Upload solche Änderungen vornehmen?

Muss ja fast so sein, da es doch einigen Leuten passiert.

Wenn ich mit dem aktuellsten Filezilla Daten in der automatischen Moduswahl hochgeladen habe, waren sie danach laut dem Tool korrupt. Im Binärmodus hingegen ist alles fein.

Aber eigentlich ist Automatikmodus doch "gut". Es scheint also so zu sein, dass das Check-Tool do etwas zu streng ist, und false positives ausgibt. Oder hat jemand schon nachgewiesen, dass diese "corrupt"-Files problematisch sind? Mir ist es auch lieber, wenn bei meiner Installation alles Grün ist, statt was zu riskieren, aber macht "Automatik" die Installation wirklich kaputt? Ich denke nicht...

Stefan

Dazu müste man so eine "korrupte" Datei mal mit der originalen binär vergleichen um so prüfen, wo nun genau das Problem liegt.

D.h. per auto uploaden, binär wieder zurück und dann vergleichen.

Zitat:

---

Zitat von BugBuster

Dazu müste man so eine "korrupte" Datei mal mit der originalen binär vergleichen um so prüfen, wo nun genau das Problem liegt.
D.h. per auto uploaden, binär wieder zurück und dann vergleichen.

---

Mach doch mal eben, mir fehlt gerade leider die Zeit.

sobald ich zu Hause bin und bei mir das überhaupt korrupt wird.
Habe ich noch nicht getestet, das neue Tool wollte ich heute mal probieren.
(Meine Seite läuft ja, daher hatte ich noch nicht die Notwendigkeit)

Zitat:

---

Zitat von dl1ely

aber macht "Automatik" die Installation wirklich kaputt

---

Nein, ganz sicher nicht. Dem PHP-Parser ist es in der Regel egal, welche Zeilenvorschübe verwendet werden.

Die Seiten laufen auch!
Scheint sich nicht wirklich auszuwirken.

Wobei die \n und \r Geschichten doch nur die Unterschiede der Betreibssysteme ausmachen, wie xtra schon erwähnte.
Nur ist gut. :)

Das heißt aber auch, dass für TL eben nur die strikte Einhaltung von Binärübertragung empfohlen werden sollte.

Und scheinbar machen das viele Tools.
FlashFXP, Filezilla, WinSCP perses und andere sicherlich auch.

Zitat:

---

Zitat von Thomas

Und scheinbar machen das viele Tools.
FlashFXP, Filezilla, WinSCP perses und andere sicherlich auch.

---

Nö. Das must Du denen schon sagen, das sie das sollen.

Das meinte ich ja!
Die meisten haben die Automatik standard mäßig aktiviert.

Wenn man z. B. Filezilla frisch installiert, ist das die Default-Einstellung.

Ich lade meine Dateien aber immer im Automatikmodus hoch (YummyFTP auf dem Mac, WinSCP auf Windows 7) und habe das Problem nicht. Außerdem wenn es so wäre, müssten dann nicht mehr als 20 von 1800 Dateien von dem Problem betroffen sein?

Könnte es damit zusammenhängen, mit welchen Zeichensatz die Dateien aus dem Editor gespeichert werden?

Ich erwische mich hin und wieder auch dabei, dass ich darauf nicht achte.

Hallo Leo.
Ich habe festgestellt, dass in deinen mitgelieferten md5 Summen meistens der MD5 Wert der Text Überragung steht, bei einigen aber der md5 Wert von der Binär Übertragung. Nanu?

Ich habe es jetzt nur an einem Beispiel getestet der bei mir corrupten Files.
plugins/tcpdf/README.TXT
Diese Datei ist nicht in "isAsciiFile" definiert.
Der gespeicherte md5 Wert ist identisch wenn ich die Datei binär übertrage!
Zum Vergleich, der md5 Wert der Changelog.txt ist identisch wenn ich es als Text übertrage.

Also entweder stehen falsche md5 Summen teilweise drin, oder aber es fehlen Einträge in der "isAsciiFile" Liste.
Letzteres vermute ich, da Teile von den Plugins bereits dort drinstehen.

Anbei mal meine Liste der angeblich corrupten Files:

Leider sind nicht alle Plugins so kodiert wie TYPOlight (UTF-8 und kein CR), aber ich sehe keinen Sinn darin, nach jedem TinyMCE-Update 500 Dateien anzupassen, nur damit sie einheitlich kodiert sind - was ja absolut keine Auswirkungen auf die Funktionsfähigkeit hat.

Die Plugin-Dateien sind also im Originalzustand auf meinem System und werden bei Dir nur falsch angezeigt, wenn Dein FTP-Programm an den Zeilenvorschüben herumschraubt. Genau das sollte es aber nicht tun!

Äh, ich nutzte hier zum Test WinSCP im Automatik Modus.
Das hattest Du doch weiter oben auch so beschrieben.

Ich hatte aber nicht erwähnt, dass man WinSCP dazu konfigurieren soll, an den Zeilenvorschüben zu schrauben, oder?

Automatisch ist aber per default nunmal so definiert, das php css etc im Textmodus überragen werden. Ich habe nichts verstellt oder eingestellt.

Ich hab kein Problem damit, ich übertrage bei mir generell im Binär Modus.
Ich war hier nur neugierig, warum der Textmodus nicht bei allen sondern nur bei einigen Dateien den corrupt Status erzeugt.

Es hat nichts mit Binär oder Ascii zu tun! Man kann Dateien auch im Ascii-Modus übertragen und dabei nichts an den Zeilenvorschüben ändern (siehe Screenshot). Wenn man beim Hochladen eine Änderung vornimmt, stimmt der MD5-Hash danach natürlich nicht mehr.

Ich denke, ich komme dem Fehler allmählich auf die Schliche. Zum Beispiel die "plugins/tcpdf/README.txt" ist weder im reinen Unix- noch im reinen Windows-Format. Sie ist ein Zwitter mit 87 LFs und 79 CRs. So etwas entsteht wohl, wenn verschiedene Leute an einer Datei arbeiten und per SVN jeweils ihre Zeilenvoschübe zusammenmergen. In diesem Fall ist der Systemcheck natürlich überfordert - noch :)

Dann erklär mal bitte was Ascii Modus dann noch für einen Sinn hat?
Per FTP kann ich ja nur zwischen den Modi wählen, nicht was er da tun soll, oder?

Und WinSCP stellt dieses Verhalten nach.
Ich kann auch in WinSCP nicht sagen was er tun soll im Ascii Modus.

Und, im deinem Screenshot steht doch auch, das du die in Unix Zeilenvorschub wandelst.

Aber seis drum, ich habe wie gesagt das Problem nicht.
Seit Apache / PHP mit beiden Varianten umgehen kann ist es ja egal wie man überträgt.

Ich denke jeder weiß was er zu tun hat damit "alles grün" wird, um mehr gehts hier nicht.

Zitat:

---

Zitat von leo

Zwitter mit 87 LFs und 79 CRs.

---

Oje, da muss ich Dir zustimmen, wer mach denn sowas....
Das erklärt dann einiges.

Ich habe eine neue Version hochgeladen. Bitte noch mal testen.

Was soll ich sagen: Alles grün :D

Super!

OK, dann wird das wohl des Rätsels Lösung sein :-).

Stefan

Hallo,

ich habe mir das mal angesehen und jetzt funktioniert es bei mir problemlos.
Beim genauen durchsuchen ist mir jedoch aufgefallen, dass nur die Kommentare in der Form
/* bla bla */
bei der Berechnung der Checksum ausgenommen werden. (Zeile 354)
Einzeilen Kommentare der Form
// bla bla
gehen weiterhin in die Checksum ein.

Wäre natürlich schön, wenn diese auch ignoriert würden (wirkt sich jedoch aktuell nicht aus).
Meine erste Idee mit dem folgenden Pattern zu suchen und zu ersetzten würde wohl beim Mac scheitern und nur unter Windows und Linux laufen:
@//.*\n@U

Zitat:

---

Zitat von xtra

Du hast bedacht, dass es 3 verschiedene Zeilenumbryche gibt? Das wird mir naemlich in meinen Entwicklungen auch immer mal wieder zum Verhaengnis.
Windows: \r\n
Unix: \n
Macintosh(vor OSX): \r

---

Das scheitert, weil ja in Zeile 350 bereits die \r gelöscht wurden.
Vielleicht gibt es ja auch eine bessere Idee, oder die Kommentarform ist einfach irrelevant...

N.Parker

Es werden nicht grundsätzlich alle Kommentare ignoriert, sondern nur solche, in denen sich eventuelle automatisch generierte SVN-Tags befinden können (z.B. $Date$). Insofern passt es so wie es jetzt ist.

Ich getraute mich ursprünglich gar nicht zu meckern, da der Web ja soweit lief.

Jetzt ist alles "Green-Tl-check".

Gruss
jachen

Zitat:

---

Zitat von leo

Es werden nicht grundsätzlich alle Kommentare ignoriert, sondern nur solche, in denen sich eventuelle automatisch generierte SVN-Tags befinden können (z.B. $Date$). Insofern passt es so wie es jetzt ist.

---

Schlagendes Argument, ich ziehe meinen Kommentar zurück!
War nur so eine Idee, da ich gerne beim Durchforsten von Quellcode selbst noch einen paar Kommentar einfüge. Nur so für mich, zur Orientierung. Mache das allerdings auch primär mittels /**/.

N.Parker

Bei mir ist jetzt auch alles grün, hatte vorher nach Upload aus SVN-Repository mit Filezilla im Automatic-Modus ca 600 mal corrupt. Danach mit binär-Modus ca 60 corrupt, jetzt alles grün.

hallo,

ich habe eine seite für einen kunden in einem unterordner entwickelt, dann habe ich die komplette installation ins root-verzeichnis verschoben:

seither übernimmt typolight keine änderungen mehr an den css dateien und auch wenn ich die css dateien neu importiere erkennt typolight gar keine css datei mehr.

habe das system check tool ausgeführt und habe jede menge corrupter dateien:

http://www.mathiasgreule.de/typolight-check.php

das verschieben der typolight installation wurde auf einem PC mit filezilla erledigt, kann dabei irgendetwas schiefgegangen sein?

so funktioniert im moment gar nichts mehr!

besten dank für eventuelle hilfe!
.christoph

Hallo Christoph,

ich denke nicht, dass es an den corrupten Dateien liegt. Die habe ich mittlerweile auch wieder, keine Ahnung wieso. Solange es läuft ist es mir mittlerweile egal.

Lass noch mal das Installtool laufen, wenn das nix bringt schau mal, ob du in den Einstellungen noch den Pfad zu dem vorherigen Ordner drin hast, oder vielleicht auch noch in der .htaccess.

Wenn du nicht gerade in Filezilla einen Filter eingestellt hast kann bei dem Rüberschieben auch nichts passiert sein.

Gruß, Andreas