Hallo

Vorweg Informationen zu den verwendeten Systemen.

Server: Root-Server Linux Debian Etch mit ProFTP
Getestet mit Filezilla. Upload der Dateien ohne Probleme.

idFTP ist die mitgelieferte Version von Delphi 2010 Pro (10.5.5)
Transfertype geestet mit ftASCII und ftBinary sowie PassivMode True/False

Anmeldung am Server erfolgt ohne Probleme. Löschen der Dateien ebenfalls.
Dann Lade ich zwei Dateien hoch. Eine XML Datei(Enthällt Update Informationen)
und ein Archive erstellt mit AbZipKit (Enthällt das Update). Dies geschieht auch
ohne Probleme.

Gehe ich dann mit meinem zweiten Programm hin und möchte die Dateien via http
herunterladen.
Die XML Dateiist auch komplett. Diese kann ich ohne Probleme lesen. Es feht dort
auch nichts. Lade ich dann das Archive herunter klappt dies zwar auch, bis ich
es wieder in die AbZipKit Komponente laden möchte. Dann bekomme ich eine
Fehlermeldung. Damit mag ich hier aber nicht nerven, denn daran liegts nicht.

Vergleiche ich die beiden Dateien miteinander Lokal vorm Update mit der auf dem FTP,
so fehlt auf dem FTP ca. 40 Byte.
Habe dann testweise ein Bild hoch geladen. 64.956 Byte Lokal. Auf dem FTP dagegen
nur 64.955 also es fehlt ein Byte. Nochmals getestet mit einer Exe auch hier über
40 Byte die fehlen. Leider habe ich über die Suche bisher nichts passendes
gefunden.
Lade ich die Dateien mit Filezilla hoch so sind sie vollständig.

Ist mit diesem Problem schon jemnand konfrontiert worden und hat dafür eine
Lösung?

Wenn Dateien im "Text-Modus" übertragen werden, dann wird vom FTP-Server der Zeilenumbruch angepaßt.

Also wird auf einem Linux-Server z.B. aus jedem #13 (CR) oder #13#10 (CRLF) ein #10 (LF).

Handelt es sich nicht um Textdateien oder soll dieses nicht angepaßt werden, dann muß man die Dateien im "Binär-Modus" übertragen.
Also ftASCII.

Bei deinem D7 wird man wohl auf die anfänglichen Indy für Delphi 2009-Unicodeproblemchen nicht eingehn.

Tipp: Schau dir mal die Dateien an und vergleiche sie auf Binär-Ebene, um über die Unterschiede auf ein bestimmtes Problem schließen zu können.


PS: Dazu gibt es mit Sicherheit auch schon ein paar Threads, wo sowas schonmal erkärt wurde,
eventuell auch mit anderen Hinweisen auf änhnliche Probleme.

Hab mal mein Profil überarbeitet. Habe D2010 Professional und Indy 10.5.5 Habe ich aber auch im Thread geschrieben.
Wie gesagt habs im ASCII und im Binary versucht. Beides ohne Erfolg.

Was Deinen lezten Tip angeht, wonach sollte ich da genau suchen? Habe es mit idftp, put, falsche, grösse versucht in Kombinationen natürlich auch in Google aber da hat sich leider nichts mit diesem Problem beschäftigt.

Werde aber mal die Dateien vergleichen, auch wenn ich persönlich daraus sicher nicht schlau werde

Habe nochmal zwischen ASCII und Binary getestet. jeweils selbe Dateigrösse.
Ich hänge sie hier mal an, denn schlau werde ich daraus leider nicht beim Vergleichen.

Login.png ist das Original Login1.png ist durch idFTP bearbeitet worden

Der Binärvergleich zeigt eindeutig dass Login1.png im Ascii-Mode übertragen wurde, wodurch gleich am Anfang der Datei ein Byte entfernt und so die Datei zerstört wurde. Jetzt liegt es an Dir, herauszufinden wo der Fehler liegt und warum der Transfer nicht im Binärmodus stattfand.

OK.. Also es ist in der Komponente definitiv Binary aktiv. Zur sicherheit habe ich mal vor dem Put ebenfalls nochmal Binary gesetzt.
Jedoch wieder die Datei hin...

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm2.IdFTP1AfterClientLogin(Sender: TObject);
  var
    SL: TStringList;
    FS: TMemoryStream;
    I: Integer;
begin
  StatusFrm.Add('Connected. Cleaning Directory');

  if CleanUpFTP then begin
    StatusFrm.Add('Create Update Info File');
    SL := TStringList.Create;
    //SL.Add(Format('<?xml version="1.0" encoding="UTF-8" standalone="yes"?>', []));
    SL.Add(Format('<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>', []));
    SL.Add(Format('<updateinfo>', []));
    SL.Add(Format(' <filename>%s</filename>', [edtFileName.Text]));
    SL.Add(Format(' <size>%d</size>', [GetFileSize(AppDir + edtFileName.Text)]));
    SL.Add(Format(' <version>%s</version>', [edtVersion.Text]));
    SL.Add(Format(' <published>%s</published>', [DateTimeToStr(Now)]));
    SL.Add(Format(' <changelog>', []));
    for I := 0 to mmoDescription.Lines.Count - 1 do
      SL.Add(Format(' <line>%s</line>', [mmoDescription.Lines.Strings[I]]));
    SL.Add(Format(' </changelog>', []));
    SL.Add(Format('</updateinfo>', []));
    FS := TMemoryStream.Create;
    SL.SaveToStream(FS);
    FS.Position := 0;
    StatusFrm.Add('Write Update Info File');
    IdFTP1.Put(FS, 'update.xml');
    StatusFrm.Add('Write Update File');
    FS.Clear;
    fs.Position := 0;
    fs.LoadFromFile(AppDir + 'Login.png'); //edtFileName.Text);
    FS.Position := 0;
    IdFTP1.TransferType := ftBinary;
    IdFTP1.Put(FS, 'Login.png'); //edtFileName.Text);
    StatusFrm.Add('Disconnecting');
    try
      IdFTP1.Disconnect;
    except
      on E: EIdConnClosedGracefully do begin

      end;
    end;
    StatusFrm.Add('Delete Update File');
    //DeleteFile(AppDir + edtFileName.Text);
  end;
end;

Client System ist Windows 7 Professional 64. Könnte es unter Umständen daran liegen?

Hast Du Zugriff auf die Logfiles des FTP-Servers? Mich würde einmal interessieren wie der Server den Upload protokolliert. Ich habe gerade mal in Source von mir geschaut, ausser dass ich nicht mit einem Memorystream arbeite sondern die Datei direkt von der Platte hochlade sieht mein Code nicht nennenswert anders aus als Deiner. Kannst Du evtl. mal ausprobieren ob sich das Verhalten ändert wenn du die Login.png direkt von der Platte hochlädst anstatt sie erst in den Memorystream zu schaufeln?

Klar habe ich zugriff, ist ja immerhin mein Root Server

War allerdings ein wenig Arbeit das log zu suchen. Ist nicht dort wo ich es vermutet hatte.

Hier wird nun auch deutlich, sofern ich das richtig lese, das mein Delphi bzw. die idFTP es im ASCII Mode

Zitat:

File Zilla
Sun Jan 2 00:29:07 2011 0 ... 71960 /home/dsnprogupdater/Login.png b _ i r dsnprogupdater ftp 1 * c

Delphi mit Indy 10.5.5
Sun Jan 2 00:32:02 2011 1 ... 71959 /home/dsnprogupdater/Login.png a _ i r dsnprogupdater ftp 1 * c

markieren

Delphi-Quellcode:

    //IdFTP1.Put(AppDir + edtFileName.Text, edtFileName.Text); <-- Hatte es versucht.
    FS.Clear;
    fs.Position := 0;
    fs.LoadFromFile(AppDir + 'Login.png'); //edtFileName.Text);
    FS.Position := 0;
    IdFTP1.TransferType := ftBinary;
    IdFTP1.Put(FS, 'Login.png'); //edtFileName.Text);

Ich hatte es vorher als direkt Upload gehabt. Als dies nicht klappte, habe ich es mit dem Stream versucht. Egal wie, es ist immer eine defekte Datei.

Hab nun das Problem gefunden.
Die Delphi 2010 Indy's sind wohl nicht gerade das wahre.

Habe die Aktuellste Version gerade installiert und nun funktioniert es auch.
Datei wird im Binary Modus übertragen und ist unbeschädigt.

Bedanke mich aber bei Dir OldGrumpy für die Hilfe.
Hätte nicht gedacht das dort der Fehler liegt.

Schön dass das Problem gelöst ist, auch wenn es weniger schön ist, dass die mitgelieferte Version der Indys so eine Gurke ist. Aber das Spielchen kenne ich schon aus früheren Delphiversionen, ich hatte es nur verdrängt Ich kenne sogar mindestens einen Entwickler der von den Indys inzwischen derart die Nase voll hat dass er jetzt wieder auf Windows Bordmittel aufsetzt für das was er braucht (WinInet)... Das ist aber immer eine Einzelfallentscheidung, denke ich.

Jetzt wo ihr das sagt, ich glaub wir hatten letztes Jahr schonmal dieses Problem mit 2010 und dort half eenfalls ein Upgrade.
Wäre mal interessant zu wissen, ob dieses in XE behoben wurde.

[add]
jetzt weiß ich's wieder
http://www.delphipraxis.net/148129-u...ml#post1001420
http://www.delphipraxis.net/136752-f...r-datei-2.html