Hallo,
ich habe folgendes Netzwerk aufgebaut. 1. Windows XP Prof. Workstation(P4, 2,8 GHz) mit einem ns83820 NIC zum Linux Fileserver(1Gbit/s full), einem Broadcom onboard LAN Chip(10 MBit/s)(ADSL nach draußen) und einem 3COM NIC zum switch(100 MBit/s full für Notebook etc.) 2. SuSE 8.1 Fileserver (P2 300 MHz) ebenfalls mit einem ns83820 NIC zur Windows XP Workstation(1 GBit/s Crosslink) und einer NE2000 zur dbox (Crosslink 10 MBIT/half)
Alle Rechner benutzen die Windows Workstation als Gateway nach draußen. Als kernel auf dem linux Rechner läuft ein 2.4.20 + pre 4 patch + ac6 patch.
Folgendes Problem tritt auf: Wenn ich ein großes Archiv(50 MB mit Winrar gepackt) von meiner WinXP Workstation zum einem samba share übertrage und danach wieder zurück zur WinXP Workstaion, ist die Checksumme falsch und das Rachiv lässt sich nicht mehr auspacken. Das gleiche passiert auch wenn ich das ganze nicht per samba, sondern per FTP mache. Teilweise passiert es auch, das Archive die ich per wget direkt auf den Linux rechner lade(über den winXP als Gateway) korrupt sind(z.B. samba-latest.tar.gz , ca 5 MB), tar sagt dann etwas von unknown 64 Bit Headern. Das Problem tritt bei Rar Archiven genrell, bei tar Archiven nur temporär auf(linux-2.4.20.tar.gz hatte keinen Fehler). Ich habe in einem posting(gesucht bei groups.google.com im Zusammenhang mit samba und CRC Error) gelesen, dass es was damit zu tun habe könnte, dass manche Archive nicht "seriell" angelegt sind, also dass der Dateizeiger wieder an den Anfang springt. Bin für jede Hilfe dankbar.
Grüße, Markus Hüwe
Markus Hüwe wrote:
Wenn ich ein großes Archiv(50 MB mit Winrar gepackt) von meiner WinXP Workstation zum einem samba share übertrage und danach wieder zurück zur WinXP Workstaion, ist die Checksumme falsch und das Rachiv lässt sich nicht mehr auspacken. Das gleiche passiert auch wenn ich das ganze nicht per samba, sondern per FTP mache.
Bin für jede Hilfe dankbar.
Hm. Ich hatte solche Probleme noch nie, benutze aber auch kein XP. In der Firma setzen wir aber auch XP ein, nie hat es aber Probleme gegeben.
Was du bei dieser Mischung allerdings beachten solltest, ist das Windows und Linux unterschiedliche Zeilenende-Kennungen haben. Windows verwendet die Kombination "\r\n" und Linux nur "\n". Vor allem bei FTP-Programmen, die auf Windows laufen, sollte man bei .tar.gz oder .zip darauf achten, das die Uebertragung im "BINARY" Modus vorgenommen wird, damit nicht uebertragene "\n" zu "\r\n" expandiert werden.
Weiterhin passiert es auch schon mal, das FTP-Uebertragungen nicht vollstaendig durchlaufen. Ein Vergleich von Pruefsummen sollte nach der Uebertragung immer vorgenommen werden. Gebraeuchlich ist, das die Projektseiten eine md5sum zu den Archiven veroeffentlichen. Du musst dann nach der Uebertragung "md5sum archiv.tar.gz" aufrufen und die Zeichenketten vergleichen.
Peter
Hm. Ich hatte solche Probleme noch nie, benutze aber auch kein XP. In der Firma setzen wir aber auch XP ein, nie hat es aber Probleme gegeben.
Bei mir im Büro gibt es auch keine Probleme. Allerdings benutzen wir auch kein Gbit Netzwerk
Was du bei dieser Mischung allerdings beachten solltest, ist das Windows und Linux unterschiedliche Zeilenende-Kennungen haben. Windows verwendet die Kombination "\r\n" und Linux nur "\n". Vor allem bei FTP-Programmen, die auf Windows laufen, sollte man bei .tar.gz oder .zip darauf achten, das die Uebertragung im "BINARY" Modus vorgenommen wird, damit nicht uebertragene "\n" zu "\r\n" expandiert werden.
Ist bekannt und wäre ein guter Ansatz, wenn das Problem nicht auch mit samba auftreten würde.
Weiterhin passiert es auch schon mal, das FTP-Uebertragungen nicht vollstaendig durchlaufen. Ein Vergleich von Pruefsummen sollte nach der Uebertragung immer vorgenommen werden. Gebraeuchlich ist, das die Projektseiten eine md5sum zu den Archiven veroeffentlichen. Du musst dann nach der Uebertragung "md5sum archiv.tar.gz" aufrufen und die Zeichenketten vergleichen.
Unwahrscheinlich, weil der server doch zurückmeldet, das STOR erfolgreich abgeschlossen wurde.
Ich hatte noch vergessen zu sagen, dass auf dem linux Rechner die Shares alle eine ext3 Partition darunter haben...
Markus
Moin,
Am Mon, 2003-02-24 um 11.53 schrieb Markus Hüwe:
Modus vorgenommen wird, damit nicht uebertragene "\n" zu "\r\n" expandiert werden.
Ist bekannt und wäre ein guter Ansatz, wenn das Problem nicht auch mit samba auftreten würde.
Ich weiss, daß mindestens zwei weitere Netzwerk-Filesysteme, nämlich NFS und AppleTalk, ebenfalls "TEXT"-Modi anbieten - also Konversion der Umbrüche und garantiert zerstörte Binärdaten. Ich _glaube_, daß man auch Samba so (ver)konfigurieren kann.
Ein einfacher Test wäre, du würdest die eine sehr große Textdatei erstellen und die hin-und herschieben. Wenn die Datei heile bleibt, hast du vielleicht so eine Fehlkonfiguration. Geht die Datei auch in' Eimer - dann vergiss meine Mail.
Gruß, Ratti
Moin,
...
Ein einfacher Test wäre, du würdest die eine sehr große Textdatei erstellen und die hin-und herschieben. Wenn die Datei heile bleibt,
hast
du vielleicht so eine Fehlkonfiguration. Geht die Datei auch in' Eimer
-
dann vergiss meine Mail.
Gruß, Ratti
Das habe ich probiert, ich habe eine 512 MB große Datei mit Nullen gefüllt und sie per FTP und samba hin und her geschoben. Sie hat sich nicht verändert. (überprüft mit md5sum und cmp)
Danach habe ich eine binär Datei verschoben und wiederum md5sum drüber laufen lassen, das Ergebnis war, dass sie sich verändert hatte. Ich habe mir daraufhin "compare"(ftp://ftp.berlios/pub/compare/) besorgt und die Datei damit Byte für Byte verglichen(vergleichen lassen), die Datei war 270 MB groß.
/opt/schily/bin/compare -all /video/sp_pak1.pk3 /video/sp_pak1.pk31 | less Folgende Ausgabe: (Die Leerzeile habe ich eingefügt, wegen der Übersichtlichkeit)
21521082 (0x14862ba) 0x22 != 0xdb " ~[ 21521083 (0x14862bb) 0xb2 != 0xc0 ~2 ~@ 21521084 (0x14862bc) 0xf8 != 0xb8 ~x ~8 21521085 (0x14862bd) 0x54 != 0xb8 T ~8 21521086 (0x14862be) 0xcd != 0xb6 ~M ~6 21521087 (0x14862bf) 0x7f != 0xf1 ^? ~q 21521088 (0x14862c0) 0xe4 != 0x95 ~d ~^U 21521089 (0x14862c1) 0x4c != 0x07 L ^G
21521090 (0x14862c2) 0xdb != 0xff ~[ ~^? 21521091 (0x14862c3) 0xc0 != 0x56 ~@ V 21521092 (0x14862c4) 0xb8 != 0x8a ~8 ~^J 21521093 (0x14862c5) 0xb8 != 0x09 ~8 ^I 21521094 (0x14862c6) 0xb6 != 0x7e ~6 ~ 21521095 (0x14862c7) 0xf1 != 0x91 ~q ~^Q
Scheinbar geht also etwas verloren, die Frage ist auf welcher Schicht...
Gruß, Markus
Hallo,
On Tue, 25 Feb 2003, Markus Hüwe wrote:
Danach habe ich eine binär Datei verschoben und wiederum md5sum drüber laufen lassen, das Ergebnis war, dass sie sich verändert hatte.
Generier mal ne Datei mit Zeilenumbruechen:
echo -en '\0\r\n\0\r\0\n\0\r\n\0' > testdatei
dann schieb die durch's Netzwerk und vergleiche das Ergebnis und das Original mit 'hex' oder 'od -t x1'...
-dnh
Hallo Markus,
Markus Hüwe wrote:
Wenn ich ein großes Archiv(50 MB mit Winrar gepackt) von meiner WinXP Workstation zum einem samba share übertrage und danach wieder zurück zur WinXP Workstaion, ist die Checksumme falsch und das Rachiv lässt sich nicht mehr auspacken. Das gleiche passiert auch wenn ich das ganze nicht per samba, sondern per FTP mache.
Bin für jede Hilfe dankbar.
Probier mal "kernel oplocks = No" in der globalen und "oplocks = No" bzw. "level2 oplocks = No" in der Share-Sektion. Außerdem: Ist bei Dir "write cache size" größer Null? Wenn ja, auf Null stellen.
Thorsten.
-
David Haller -
Jörg Roßdeutscher -
Markus Hüwe -
Peter Wiersig -
Thorsten D. Marsen