Jede Menge corrupter Dateien bei Typolight-Check!

**Thomas** · 21.02.2010, 21:33

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.

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!

**MacKP** · 21.02.2010, 21:35

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

Eventuell hilft das weiter.

Viele Grüße

**Thomas** · 21.02.2010, 21:44

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.

**MacKP** · 21.02.2010, 21:47

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

**acenes** · 21.02.2010, 21:49

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.

**Thomas** · 21.02.2010, 21:51

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.

**MacKP** · 21.02.2010, 21:55

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?

**Thomas** · 21.02.2010, 21:58

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.

***Nina*** · 21.02.2010, 21:59

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).

**acenes** · 21.02.2010, 22:00

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.

**Thomas** · 21.02.2010, 22:00

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

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.

***Nina*** · 21.02.2010, 22:03

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

**Thomas** · 21.02.2010, 22:05

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.

**acenes** · 21.02.2010, 22:07

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.

**Thomas** · 21.02.2010, 22:09

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

Meine Probleme mit der Kommentarfunktion sind dennoch nicht behoben.

***Nina*** · 21.02.2010, 22:10

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:

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

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.

**MacKP** · 21.02.2010, 22:11

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

***Nina*** · 21.02.2010, 22:13

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.

**Thomas** · 21.02.2010, 22:14

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

***Nina*** · 21.02.2010, 22:30

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.

***leo*** · 22.02.2010, 09:32

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?

**dl1ely** · 22.02.2010, 10:26

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

**xtra** · 22.02.2010, 11:42

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.

***leo*** · 22.02.2010, 16:25

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 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?

***Nina*** · 22.02.2010, 16:30

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.

**dl1ely** · 22.02.2010, 16:35

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

**BugBuster** · 22.02.2010, 16:39

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.

**xtra** · 22.02.2010, 16:55

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.

**BugBuster** · 22.02.2010, 16:57

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)

***leo*** · 22.02.2010, 17:04

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.

**Thomas** · 22.02.2010, 17:09

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.

***lucina*** · 22.02.2010, 17:33

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.

**Thomas** · 22.02.2010, 17:36

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

***Nina*** · 22.02.2010, 18:17

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

***leo*** · 22.02.2010, 19:39

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?

**Thomas** · 22.02.2010, 19:45

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.

**BugBuster** · 22.02.2010, 20:17

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:

***leo*** · 22.02.2010, 20:21

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!