FTP-Upload fehlerhaft

tklustig

Erfahrenes Mitglied
Hallo Leute,
ich habe eine FTP-Klasse programmiert, die für unserere Applikation das Hoch-und Runterladen sowie Löschen von Dateien organisiert. Die Zugangsdaten kommen aus einer Datenbank. Der Code funktioniert soweit. Wenn ich allerdings über FileZilla die hochgeladenen Dateien auf meinen Desktop runterlade und öffnen möchte, werden Word-Dateien und PDF-Dateien als fehlerhaft("Diese Datei ist beschädigt und kann nicht repariert werden") bezeichnet und nicht geöffnet. Dieses Phänomen tritt nicht bei Bildern (*.jpeg,*.bmp etc..) und Textdateien (*.txt) auf. Das bedeutet, dass mein Code stimmig ist. Meine Frage ist nun folgende: Weiß jemand, welche Konfigurationseinstellungen in der PHP.INI dafür verantwortlich sein könnten, dass der Upload nicht korrekt funktioniert. Folgende Parameter habe ich gesetzt:
post_max_size=8M
upload_max_filesize=10M
max_file_uploads=20
;opcache.max_file_size=0

Woran könnte es sonst liegen?
Hier noch der Code, der den Übertragungsmodus festlegt
PHP:
    public function DateienHochloaden($render, $connection, $localFile, $LocalDirectory) {
        $session = new Session();
        $docx = '/docx/';
        $txt = '/txt/';
        $pdf = '/pdf/';
        $xlsx = '/xlsx/';
        $pptx = '/pptx/';
        //  try {
        $basis = $this->GetZugangsDaten($render);
        $SourceDirectory = $basis[3];
        if (preg_match($docx, $localFile) || preg_match($txt, $localFile) || preg_match($pdf, $localFile) || preg_match($xlsx, $localFile) || preg_match($pptx, $localFile))
            $mode = FTP_ASCII;
        else
            $mode = FTP_BINARY;
.
.
Jede konstruktive Antwort ist willkommen. Ich bin mit meinem Latein am Ende:(
P.S.: Die Beschädigung ist nicht abhängig von der Dateigröße. Sie tritt selbst bei kleinsten Word-Dokumenten(13 KB) auf....
 
Zuletzt bearbeitet:
Ist es bei anderen Programmen ebenso der Fall?

Prüf es mal mit CyberDuck.
Sicher dass es beim Hochladen keine Fehler gibt?

Prüf mal wenn Du via Hand eine Word-Datei erstellst und sie dann hochlädst.
Prüf auch die Variablen mir var_dump(), durchaus möglich dass es er zwar die Datei hochläd, sie aber bei 99,9% abbricht, sie dir trotzdem als 100% durchkommt.

Vielleicht hift dir das: http://php.net/manual/de/ftp.installation.php

Habe zwar nicht soviel Ahnung von FTP, aber hatte auch immer meine Probleme mit Upload-Formularen ^^
 
Der Fehler tritt definitiv während des Uploads durch PHP auf. Wie gesagt, nur bei WORD und PDF Dateien.
PHP:
$putFile = $connection->put($SourceDirectory . $localFile, $LocalDirectory . $localFile, $mode);
var_dump($putFile);
var_dump($SourceDirectory.$localFile);
ergibt folgendes:
PHP:
E:\xampp\htdocs\yii2_perswitch\common\wsl_components\FTPZugang.php:89:boolean true

E:\xampp\htdocs\yii2_perswitch\common\wsl_components\FTPZugang.php:90:string '/FTP_Server/Diverses/12_Joinabfragen.docx' (length=41)
Nix, was mir weiterhelfen würde:mad:
Ein Vergleich der Dateigrößen zeigt auf ,dass das hochgeladene Worddokument wesentlich kleiner ist, als das Original. Warum, entzieht sich jedoch meiner Kenntniss.....
 
Zuletzt bearbeitet:
Hi

wie viel kleiner ist "wesentlich"?
Stimmt die kleinere Datei 1:1 mit dem Anfang der größeren überein?

Und "warum" suchst du dir für docx usw. den Textmode aus, statt Binary? Das ist sehr wahrscheinlich das Hauptproblem hier...

Zumindest dass du gerade mit diesen Dateitypen Probleme hast sollte eigentlich schon von weitem sichtbar sein ... Textmode macht nur in bestimmten Fällen Sinn; beliebige Dateien 1:1 kopieren ist nie dabei. Sogar wenn es Textdateien sind (und docx ist sowieso keine)

Notiz zum Schluss: Ideal wäre, FTP gar nicht mehr zu verwenden... SFTP ist zwar umständlicher, löst aber einige prinzipielle Probleme von FTP, und ist auch verschlüsselt usw.
 
Zuletzt bearbeitet:
Bingo! Ich hatte an anderer Stelle in Erfahrung gebracht, dass für alle Textdateien FTP_ASCII verendet werden soll. Und WORD ist für mich eine Textdatei im weitesten Sinne
Wann soll ich jetzt FTP_BINARY und wann FTP_ASCII verwenden. Soll ich überhaupt FTP_ASCII verwenden. Führt der Modus FTP_BINARY nicht zu Problemen mit LINUX??
Ich habe das jetzt so abgeändert:
PHP:
    public function DateienHochloaden($render, $connection, $localFile, $LocalDirectory) {
        $session = new Session();
        $txt = '/txt/';
        //  try {
        $basis = $this->GetZugangsDaten($render);
        $SourceDirectory = $basis[3];
        if (preg_match($txt, $localFile))
            $mode =FTP_ASCII;
        else
            $mode = FTP_BINARY;
.
.
die Verwendung von Port 21 ist eine Vorgabe meines Betriebes. Mir wäre das SSL Protokoll (Port 22) auch lieber....
Vielen Dank, Admin für Deine Hilfe. Lässt mich beruhigt schlafen:rolleyes:
Hatte nämlich bereits befürchtet, meine Klasse auf'n Müll deportieren zu müssen...
 
Zuletzt bearbeitet:
Hi

SL/TLS und SSH (wo SFTP dazugehört) sind sehr verschiedene Sachen.

Zu den Ports, ich hoffe dir ist bewusst das FTP oft zwei verwendet: 21, und ein anderer ohne fixe Nummer.
Für Firewalleinstellungen usw. ein Problem - das ist eins der Gebiete, wo SFTP besser ist, da gibts nur einen Port.
Den kann man übrigens auch auf 21 einstellen, auch wenns vermutlich nicht das ist was dein Chef will :D

Binary führt nicht zu Problemen mit Linux, nein.

...

Wie und warum ist etwas umständlich .... daher zuerst dazu, was hier eine "Textdatei" ist, dann warum Docx keine ist, und dann warum FTP das überhaupt unterscheidet.

...

Vielleicht sagen dir ASCII, UTF8 usw. was - im Wesentlichen Nummernzuweisungen zu Buchstaben, wie zB. ein großes A auf Nummer 65, ein kleines a auf 97, ein kleines b auf 98., usw.
Dazu gibts auch einige Sonderfälle im Nummernbereich 0-32, wie ein Zeilenwechsel 10, oder die Nummer 7 die auf manchen Betriebssystemen beim "Anzeigen" einen Ton verursacht (weil vom betriebssystem eben so behandelt - die Nummer selber ist nur eine Nummer). Andere Nummern zwischen 0-32 beinhalten zB. Steuerbefehle für Geräte von vor 50 Jahren, die heute so keinen Sinn mehr machen, usw. (ASCII ist alt)

Um ein JPG-Bild als Beispiel zu nehmen wo diese Zuordnung NICHT angewendet wird: Die Bytes in der Datei beinhalten Informationen über die Farbpunkte im Bild usw. - die Bytes sind aber nicht dazu gedacht, als ASCII-Werte verstanden zu werden. Solange kein Programm sie so behandelt ist es also kein Problem, wenn zB. ein Byte mit Wert 7 vorkommt, es wird nicht biepen nur weil das 7-Byte da ist. Und jedes Bildanzeigeprogramm versteht auch, was es mit diesem 7-Byte machen soll (und zwar als Farbe zum Anzeigen verstehen, nicht biepen).

Eine "Textdatei" in dem Zusammenhang ist jetzt eine Datei, deren Inhalt (komplett!) als ASCII etc. verständlich ist - jedes Byte drin steht für Text, und es sind auch keine Bieps usw. vorhanden (besser gesagt, gar nichts aus 0-32 außer dem Zeilenwechsel). Solche Dateien enthalten auch keine Formatierungen wie verschiedene Schriftarten usw,, weil das abzuspeichern (welcher Textteil in welcher Schriftart ist) würde auch Platz in der Datei brauchen, der dann nicht zu eigentlichen Textinhalt gehört. Programme, um solche Dateien zu bearbeiten, gibts mehr als man Zählen kann - Beispiele sind zB. Notepad auf Windows, Notepad++, nano in Linuxkonsolen, vi, Kate, usw.usw.

...

Docx ist keine Textdatei, weil es (wie schon angesprochen) viel anderes Zeug enthält. MS Word hat tausende Funktionen, die über reines Buchstabenspeichern hinausgehen, angefangen mit Fettmarkeriung, Schritarten, über Bilder im Text, Tabellen, usw.usw. Das muss auch alles in die docx-Datei, und Word verwendet dabei auch Bytewerte aus dem 0-32-Bereich. Solange Word selber es versteht ... auch ohne die Bytewerte müsste eine docx-Datei jedenfalls viel Zusatzinformationen haben, statt nur dem Text allein, daher für Programme wie Notepad nicht wirklich geeignet. (Kannst dir eine Docx-Datei ja einmal mit so einem Plaintext-Editor aufmachen...)

...

Nachdem das geklärt wäre, gibt es in "puren" Textdateien aber noch ein Problem mit den Zeilenwechseln. Oben steht, dass der die Nummer 10 ist. Microsofts Betriebssystemabteilung macht da aber schon jahrzehntelang ein eigenes Ding - die Doktrin dort ist, dass ein Zeilenwehcsel in einer Datei aus "zwei" Byte mit den Werten 10 13 besteht, und Windowsprogramme das auch alle so machen sollen. (Apple hatte in der Vergangenheit auch eine eigene andere Variante, inzwischen haben sie sich aber auf 10 angepasst). ... Vor 20 Jahren bedeutete das, Windows, Windowsprogramme von Microsoft, und WIndowsprogramme von anderen Herstellern auch, verwendeten alle 10 13 für Zeilenwechsel. Mit einem Nur-10-Zeilenwechsel konnten sie (meistens) nichts anfangen. Andere Betriebssysteme und deren Programme hatten 10. ... Inzwischen hat sich das etwas gebessert, viele WIndowsprogramme von Drittanbietern (und sogar ein paar von MS selber), die mit Textdateien umgehen sollen, verstehen sowohl 10 13 als auch 10 (bzw. 13 wird dann einfach ignoriert, da es sonst heutzutabe nicht wirklich verwendet wird). Und umgekehrt können auch Linuxprogramme usw. mit beiden Arten umgehen. (MS selber ist aber, im Gesamten, nach wie vor nicht bereit, von 10 13 wegzugehen und einfach 10 zu verwenden).

...

Zurück zu FTP, um die ganzen Fäden zusammenzuführen:

Binary kopiert Dateien einfach Byte für Byte, wie sie sind. Egal ob es eine richtige Textdatei, oder Bilder, oder Docx, oder irgendwas anderes ist.

Zur Erinnerung, FTP ist relativ alt. Und der 10-oder-1013-Unterschied war früher ein größeres Problem für Benutzer weil viele Windowsprogramme die andere Art einfach nicht verstanden haben.
Deshalb wurde bei FTP ein Textmode dazuerfunden, der in Textdateien eine "Übersetzung" zur richtigen Zeilenwechselart machen kann. (falls nötig - also bei FTP-Verbindungen zwischen Windows und Linux, zB.). Das ist der einzige Grund, warum es den gibt. Alle 10-Byte mit 10-13 ersetzen, oder umgekehrt, während der Übertragung. Anderen Byte zwischen 0-32 können aber ein Problem sein, weil sie per Definition nicht vorkommen sollen und das FTP-Programm evt. nicht auf einen richtigen Umgang damit vorbereitet ist.
...

Für Bilder, Docx und ähnlcihe Nicht-Textfiles ist der Textmode daher Unsinn - die Bytes drin machen Sinn für Word usw., 13-Bytes irgendwo dazumachen/wegnehmen nur weil ein 10-Byte da ist kann nciht wirklich gut gehen. Und WOrd verwendet ja auch alle möglichen Werte, auch die zwischen 0-32.

Für richtige Textdateien ist der Textmode heutzutage auch nicht mehr wirklich nötig - wie gesagt können viele Programme mit beiden Zeilenwechselarten umgehen. Und je nach dem, was man tut, will man evt. ja auch einfach nur Dateien unverändert kopieren, auch wenn es Textdateien sind...
 
Das war jetzt aber eine wirklich ausführliche Antwort, die keine Unklarheiten zurück lässt. Hatte übrigens SSH statt SSL gemeint, wobei mir nicht bewusst war, dass das FTP-Protokoll auf einem anderen als Port 21 lauscht. Im übrigen geht es im wesentlichen darum, über das FTP-Protokoll schreibend auf einen anderen Webserver zuzugreifen, da mein Chef nicht will, dass die Uploaddateien auf unserem Webserver landen. Das HTTP-Protokoll verbietet bekanntlich den schreibenden Zugriff. Auf meinen eigenen Webserver(RaspberryPi) greife ich schreibend über das SSH Protokoll zu, sowohl für das HTTP als auch das HTTPS Protokoll. Der Provider, den mein Chef unterhält bietet hingegen schreibenden Zugriff über das FTP-Protokoll an. Das ist der Hintergrund der ganzen Angelegenheit....
Vielen Dank nochmals für deinen geschichtlichen Exkurs. Wegweisend und selten in Foren zu finden...
Bye!
 
Zurück