FTP-Server und Umlaute

[Olaf Erkens]

Tach Gemeinde,

ich weiß, dass es hier schon mal eine Diskussion darüber gab, kann sie
aber nicht mehr finden und da ich damals mangels passendem Netware das
Problem nicht nachvollziehen konnte, hab ich's auch nur überflogen.

Gegeben: Netware 6.5 SP7 mit dem dazu gehörigen FTP-Server. Auf den
NSS-Dateisystemen natürlich LONG-Namespace (neben MAC und NFS) mit
allen dazu gehörenden Schattenseiten. Mit dem Remote Manager kann ich
Dateien mit Umlauten problemlos übertragen, aber der macht ja auch
http.

Mir ist klar, dass FTP, weil es im Protokoll nicht vorgesehen ist, nur
7bit-Zeichen bei Dateinamen kann. Man hat sich aber wohl darauf
geeinigt, in so einem Fall die Dateinamen bei der Übertragung mit UTF8
zu kodieren. Jedenfalls gibt es genug FTP-Clients, die das können.
Leider spielt der Novell FTP-Server da bei mir nicht mit. Zwinge ich
den FTP-Client, UTF8 zu machen, ändert sich zwar das "Ersatzzeichen"
bei der Anzeige des Dateinamens, aber garantiert nicht in den Umlaut,
der da eigentlich steht. So scheitert jede Übertragung.

Seltsam:
Ändere ich im FTP-Client den Dateinamen auf dem Server und schreib da
den Umlaut rein, dann wird das ausgeführt und die Übertragung klappt.
Dafür wird der Umlaut dann hinterher, wenn ich per Windows und
Netwareclient auf das Dateisystem des Servers zugreife, kryptisch
dargestellt.

Fragen:
1. Unterstützt Novell FTP UTF8 (ich vermute: ja)?
2. Wo hab ich vergessen, ein Häkchen zu setzen bzw. wie sorge ich
dafür, dass bei Dateizugriff über den Netwareclient und bei dem über
FTP der Umlaut im Dateinamen gleich aussieht?

Viele Grüße

Olaf

[Massimo Rosen]

Olaf,

Post by Olaf Erkens
Gegeben: Netware 6.5 SP7 mit dem dazu gehörigen FTP-Server. Auf den
NSS-Dateisystemen natürlich LONG-Namespace (neben MAC und NFS) mit
allen dazu gehörenden Schattenseiten.

Was für Schattenseiten?

Post by Olaf Erkens
Mir ist klar, dass FTP, weil es im Protokoll nicht vorgesehen ist, nur
7bit-Zeichen bei Dateinamen kann.

http://www.novell.com/support/viewContent.do?externalId=7001283&sliceId=1

Oder einfach: Deine ASCII Codepages stimmen nicht.

CU,

[Olaf Erkens]

Hallo Massimo,

Post by Massimo Rosen

Post by Olaf Erkens
Gegeben: Netware 6.5 SP7 mit dem dazu gehörigen FTP-Server. Auf den
NSS-Dateisystemen natürlich LONG-Namespace (neben MAC und NFS) mit
allen dazu gehörenden Schattenseiten.

Was für Schattenseiten?

Die so unter einen Hut zu bekommen, dass auf allen Clients und unter
allen Zugriffsprotokollen immer der gleiche Dateiname angezeigt wird.

Post by Massimo Rosen
http://www.novell.com/support/viewContent.do?externalId=7001283&sliceId=1
Oder einfach: Deine ASCII Codepages stimmen nicht.

Hmm - ich habe auf dem Server Codepage 850. Was ist daran falsch?

Wenn das falsch ist ... wie biege ich das um, ohne die bestehenden
Dateinamen zu "gefährden"?

Viele Grüße

Olaf

[Massimo Rosen]

Hallo,

Post by Olaf Erkens
Hallo Massimo,

Post by Massimo Rosen

Post by Olaf Erkens
Gegeben: Netware 6.5 SP7 mit dem dazu gehörigen FTP-Server. Auf den
NSS-Dateisystemen natürlich LONG-Namespace (neben MAC und NFS) mit
allen dazu gehörenden Schattenseiten.

Was für Schattenseiten?

Die so unter einen Hut zu bekommen, dass auf allen Clients und unter
allen Zugriffsprotokollen immer der gleiche Dateiname angezeigt wird.

Wie soll das auch gehen? Im Gegenteil gibt es ja individuelle Namespaces
genau damit eben jede Datei *mehrere* völlig unabhängige Dateinamen
haben kann, und man sich so nicht auf den kleinsten Gemeinsamen Nenner
kastrieren muss.

Post by Olaf Erkens

Post by Massimo Rosen
http://www.novell.com/support/viewContent.do?externalId=7001283&sliceId=1
Oder einfach: Deine ASCII Codepages stimmen nicht.

Hmm - ich habe auf dem Server Codepage 850. Was ist daran falsch?

Das ist nur dann falsch, wenn der FTP Client (oder der Client der die
Dateien auf den Server geschrieben hat) was anderes nimmt.

CU,

[Jens Wilke]

Hallo Massimo,

Post by Massimo Rosen

Post by Olaf Erkens

Post by Massimo Rosen
http://www.novell.com/support/viewContent.do?externalId=7001283&sliceId=1
Oder einfach: Deine ASCII Codepages stimmen nicht.

Hmm - ich habe auf dem Server Codepage 850. Was ist daran falsch?

Das ist nur dann falsch, wenn der FTP Client (oder der Client der die
Dateien auf den Server geschrieben hat) was anderes nimmt.

Ich habe mal UTF8 im XP-Client (4.91SP5) ausgeschaltet und es hat sich
im Explorer nichts geändert (wie erwartet, denn die 4.83er zeigen die
Dateien ebenfalls alle korrekt an, ebenso das Win-FTP).
Was würde bei Cp437 passieren?

Alle FTP-Clients zeigen bei per FTP übertragenen Dateien den korrekten
Namen an, aber niemals bei den mit dem Windows-Explorer erzeugten.
Der Win-Explorer + Remote Manager zeigen wiederum immer nur "Schrott"
bei per FTP übertragen Dateien an.
NSSCPT -D -FIXNAMES bewirkt nichts.

NSSCPT -D -NONROMAN:
Files with non-Roman characters in their LONG name:

EXP_öäüÖÄÜß.txt
FTP_ANSI_õ÷³-Í_¯.txt
FTP_UNI_+ñ+Â+++ä+û+£+ƒ.txt
FZTP_AUTO_+ñ+Â+++ä+û+£+ƒ.txt
FZTP_AUTOREN_õ÷³-Í_¯.txt
FZTP_UTF8_+ñ+Â+++ä+û+£+ƒ.txt

Woran muss denn gedreht werden, damit ein vernünftiger FTP-Transfer
möglich wird?
Kann/Muss man NSS /NCPDisplayNonTranslatableNames permanent
einschalten?

Viele Grüße

Jens

[Massimo Rosen]

Hallo,

Post by Olaf Erkens
Hallo Massimo,

Post by Massimo Rosen

Post by Olaf Erkens

Post by Massimo Rosen
http://www.novell.com/support/viewContent.do?externalId=7001283&sliceId=1
Oder einfach: Deine ASCII Codepages stimmen nicht.

Hmm - ich habe auf dem Server Codepage 850. Was ist daran falsch?

Das ist nur dann falsch, wenn der FTP Client (oder der Client der die
Dateien auf den Server geschrieben hat) was anderes nimmt.

Ich habe mal UTF8 im XP-Client (4.91SP5) ausgeschaltet und es hat sich
im Explorer nichts geändert (wie erwartet, denn die 4.83er zeigen die
Dateien ebenfalls alle korrekt an, ebenso das Win-FTP).

Gut, dann weiß man schonmal, das die Dateien im Filesystem sowohl in UTF
als auch in ASCII correct sind.

Post by Olaf Erkens
Was würde bei Cp437 passieren?

Fast gar nichts bei euch, weil für Deutsche Sonderzeichen CP437 und
CP850 nahezu gleich sind. Wenn Ihr auch noch französiche Sonderzeichen
hättet, wird es interessanter.

Post by Olaf Erkens
Alle FTP-Clients zeigen bei per FTP übertragenen Dateien den korrekten
Namen an, aber niemals bei den mit dem Windows-Explorer erzeugten.

Womit dann klar ist, dass der FTP *Client* eine andere Codepage als 850
verwendet.

Post by Olaf Erkens
Der Win-Explorer + Remote Manager zeigen wiederum immer nur "Schrott"
bei per FTP übertragen Dateien an.
NSSCPT -D -FIXNAMES bewirkt nichts.

Kann das auch nicht.

Post by Olaf Erkens
Woran muss denn gedreht werden, damit ein vernünftiger FTP-Transfer
möglich wird?

*Offiziell*, dem Standard zufolge, muss man US-ASCII nehmen, und
Sonderzeichen weglasssen. Für alles andere gibt es keinerle
Funktionisgarantie. Wenn überhaupt irgendwas etwas ändert, sind das
Einstellungen am verwendeten FTP client.

Post by Olaf Erkens
Kann/Muss man NSS /NCPDisplayNonTranslatableNames permanent
einschalten?

Nein. Nondisplayablenames kann es nur geben, wenn UTF-8 clients (also
der Novell Client für WIndows), Dateinamen mit Zeichen erzeugt, die in
der aktuellen ASCII-Codepage des Servers gar nicht vorkommen. Per FTP
ist das unmöglich, da das ja wie gesagt gar kein UTF-8 kann.

CU,

[Olaf Erkens]

Hallo Massimo,

Post by Massimo Rosen
Gut, dann weiß man schonmal, das die Dateien im Filesystem sowohl in UTF
als auch in ASCII correct sind.

Wir sind inzwischen weiter. Wir haben einen einzigen FTP-Client
gefunden, bei dem es die Option gibt, abweichend von der Codepage des
Client-OS eine andere Codepage für den konnektierten Server
einzustellen (http:\\www.crossftp.com). Da der javabasiert ist, wird
er hoffentlich das noch nicht untersuchte, aber vermutlich auch bei
MacOS als Client auftretende Problem gleich mit erschlagen. Damit
werden die Umlaute zumindest von Win32 aus korrekt dargestellt.

Post by Massimo Rosen
Womit dann klar ist, dass der FTP *Client* eine andere Codepage als 850
verwendet.

Natürlich ... die allermeisten FTP-Clients verwenden die Codepage des
Client-OS. Erschreckend ist allerdings, dass Novell Netdrive genau das
Gleiche macht - auch das zeigt bei FTP-Zugriff kaputte Umlaute an.

Post by Massimo Rosen
*Offiziell*, dem Standard zufolge, muss man US-ASCII nehmen, und
Sonderzeichen weglasssen. Für alles andere gibt es keinerle
Funktionisgarantie. Wenn überhaupt irgendwas etwas ändert, sind das
Einstellungen am verwendeten FTP client.

M.E. falsch ... der Novell FTP-Server kann offensichtlich kein UTF-8
(zumindest hab ich kein Häkchen dafür gefunden und auf die
entsprechende Anfrage FEAT reagiert er mit einem "Unknown Command",
siehe RFC2640). Könnte er das, wäre die dämliche Konvertiererei nach
der Codepage des Server-OS überflüssig. Dann könnte er Umlaute bzw.
die kompletten Dateinamen schlicht UTF-8-kodiert schicken, was die
allermeisten FTP-Clients schon lange beherrschen.

Diese Theater konnten wir bisher nur mit einem Novell FTP-Server
feststellen. Daher gehe ich davon aus, dass der Mist macht bzw. Novell
da ein Konzeptproblem hat.

Viele Grüße

Olaf

[Rudolf Thilo]

Post by Olaf Erkens
Wir sind inzwischen weiter. Wir haben einen einzigen FTP-Client
gefunden, bei dem es die Option gibt, abweichend von der Codepage des
Client-OS eine andere Codepage für den konnektierten Server
einzustellen (http:\\www.crossftp.com). Da der javabasiert ist, wird
er hoffentlich das noch nicht untersuchte, aber vermutlich auch bei
MacOS als Client auftretende Problem gleich mit erschlagen. Damit
werden die Umlaute zumindest von Win32 aus korrekt dargestellt.

Wenn Du's scripten kannst (wiederkehrende Kopieraktionen selber Art),
dann wäre es für FTP.EXE einen Versuch wert, das Programm aus der CMD
Box zu starten und vorher ein

mode con cp select=850

los zu treten, dann ein

ftp.exe -s <steuerdateiname>




Schönen Gruß, Rudi.

[Olaf Erkens]

Hallo Rudolf,

Post by Rudolf Thilo
Wenn Du's scripten kannst (wiederkehrende Kopieraktionen selber Art),
dann wäre es für FTP.EXE einen Versuch wert, das Programm aus der CMD
Box zu starten und vorher ein
mode con cp select=850

Schon klar - die Codepage läuft bei uns eh im "DOS-Fenster" und mit
dem "DOS-FTP" ist das auch alles kein Problem. Hatten wir auch schon
ausprobiert ... hab ich nur vergessen zu erwähnen.

Post by Rudolf Thilo
los zu treten, dann ein
ftp.exe -s <steuerdateiname>

Ich will's mal so formulieren: Das wäre für dich wie mich ein
gangbarer Weg und wir würden alle nötigen Kommandos blind und ohne
nachzudenken hin schreiben. Wir sind als ITler aber leider irrelevant
... wir haben "nur" die Aufgabe, den Endanwender zu bedienen.

Und ich denke, wir sind und darüber einig, dass die Zeiten
kommandozeilengesteurter Tools aus Sicht eben dieses Endanwenders
schon länger vorbei sind. Damit kann ich heute niemandem mehr kommen.
KlickiBunti und Mausschubsen ... oder wird nicht benutzt. Der moderne
Endanwender kennt nicht mal mehr das windowsweit gültige und m.E.
meist schneller STRG+X/C/V :-(

Und um es ehrlich zu sagen ... natürlich geht es mit irgendwas, was
wie ein Filemanager (egal ob unter Windows oder Linux) aussieht, auch
für uns oft einfacher und schneller. Die paar Speziallfälle, wo die
völlig unzureichend sind, kommen eh meist nur bei der Arbeit von
ITlern vor.

In einer heterogenen IT-Umgebung muss ich dafür sorgen, dass, egal
welches Tool (hier FTP-Client) auf welchem OS der Endbenutzer anwendet
(und wenn es der blöde Windows Explorer ist), die Endbenutzer damit
transparent und interoperabel arbeiten können. Ein "Verwenden sie
keine Umlaute und sonstigen Sonderzeichen" wird heute nicht mehr
akzeptiert - nicht mal grummelnd. Da haut man dir höchstens was im
Stile Unfähigkeit um die Ohren. Die Zeiten sind endgültig vorbei.

Und jetzt ist Novell dran. Was deren FTP-Server da veranstaltet, ist
insbesondere vor dem Hintergrund, dass die Dateinamen als Unicode
vorliegen, ein NOGO. Und wenn ich das richtig sehe, passiert unter
OES2 mit NSS als Dateisystem das Gleiche (Widerrede?).

Viele Grüße

Olaf

[Rudolf Thilo]

Olaf Erkens wrote:

[Kommandozeile + 7bit tot. Mausschubsen angesagt. NWFTPD schei***]

Grundsätzlich ACK.


Das einzige, was ich nicht verstehe ist, *WARUM* in Gottes Namen
*MÜSSEN* die Mausschubser diese Dateien per FTP bewegen?

IMHO ist FTP aus diversen Gründen grundsätzlich für Mausschubser wenig
ideal ;)


FTP stammt aus der Dinosaurier-Zeit, und das bringt eben
Einschränkungen mit sich.
Es gibt ja genügend Alternativen, Dateien anders zu (maus)schubsen.


Schönen Gruß, Rudi.

[Massimo Rosen]

Hallo,

Post by Rudolf Thilo
[Kommandozeile + 7bit tot. Mausschubsen angesagt. NWFTPD schei***]
Grundsätzlich ACK.

Bis auf letztes, ja.

Post by Rudolf Thilo
Das einzige, was ich nicht verstehe ist, *WARUM* in Gottes Namen
*MÜSSEN* die Mausschubser diese Dateien per FTP bewegen?

Ganz genau richtig. Das alles was Olaf so eloquent und richtig ausführt,
übersieht dabei aber ganz geflissentlich, dass FTP *genau* für diese
Clientel das absolut falsche Produkt/Lösung ist. Wer unbedingt "modern"
haben will, darf eben kein FTP benutzen, daran ist nämlich *nichts*
modern, und es ist von Grund auf *nur* für die Kommandozeile entwickelt
worden, und das mekrst man an allen Ecken und Enden. Es ist total
unrealistisch, erst für eine bestimmte Anwendung ein Steinzeitprodukt
auszuwählen, und sich dann darüber zu beschweren, dass das eben auch
Steinzeiteinschränkungen besitzt. Das hätte man vorher wissen *müssen*,
und wenn das nicht akzeptabel ist, eben eine andere Lösung benutzen.

Und bevor jetzt jemand "aber nur Netware..": Dan sage ich mal
"Schwachsinn":

http://www.google.de/search?hl=de&q=ftp+umlaute+problem&btnG=Google-Suche&meta=



CU,

[Olaf Erkens]

Hallo Massimo,

Post by Massimo Rosen
Das alles was Olaf so eloquent und richtig ausführt,
übersieht dabei aber ganz geflissentlich, dass FTP *genau* für diese
Clientel das absolut falsche Produkt/Lösung ist.

Vorschläge (siehe auch Antwort an Rudolf)?

Post by Massimo Rosen
Wer unbedingt "modern" haben will, darf eben kein FTP benutzen, daran
ist nämlich *nichts* modern, und es ist von Grund auf *nur* für die
Kommandozeile entwickelt worden, und das mekrst man an allen Ecken
und Enden.

Wenn der NWFTPD UTF-8/Unicode (was das FTP etwas aus der Steinzeit
hebt) könnte und die Zwischenumsetzung in die Servercodepage damit
nicht stattfinden würde, gäbe es das Problem wohl eher nicht. Apropo
Kommandozeile: Du erinnerst dich? Früher hatten wir nur eine
Kommandozeile ... auch für's Dateimanagement oder das Erstellen einer
simplen Textdatei (man "copy con") *lach*

Post by Massimo Rosen
Es ist total unrealistisch, erst für eine bestimmte Anwendung ein
Steinzeitprodukt auszuwählen, und sich dann darüber zu beschweren,
dass das eben auch Steinzeiteinschränkungen besitzt.

Das Problem stellt sich eher anders rum dar: FTP nutzen wir schon
ziemlich lange für externe Zugriffe ... eigentlich seit NW3 mit
Fremdprodukt und seit NW4 mit dem jeweiligen Netware FTP-Server. Meine
"Kunden" habe ich bisher "in Schach" halten können, weil die unter NW4
auf dem Userserver (!= FTP-Server) eh nur kurze Dateinamen angezeigt
bekamen. Die Zeiten sind aber mit NW65 bei uns vorbei und nun erzeugen
sie fleißig Dateien mit Sonderzeichen.

Post by Massimo Rosen
Das hätte man vorher wissen *müssen*,

Wusste ich aber nicht bzw. ich hatte daraus, das NSS in Unicode
abspeichert, irriger Weise geschlossen, der NWFTPD käme damit dann
auch klar. Es nutzt aber letztlich derzeit nichts, weil wir adhoc
nicht von FTP weg kommen (wegen Mangel an Manpower).

Ich hatte halt gehofft, ich hätte irgendwo einen "Schalter" für UTF-8
übersehen. Die Blase ist leider geplatzt. Schaun wir mal, was die
Javaanwendung CrossFTP, die das Problem unter Windows ja umschifft,
aus Sicht von MacOS (hab grad keinen der Macs greifbar) veranstaltet
... nach meinem Urlaub :-)

Viele Grüße

Olaf

[Massimo Rosen]

Hallo,

Post by Olaf Erkens
Hallo Massimo,

Post by Massimo Rosen
Das alles was Olaf so eloquent und richtig ausführt,
übersieht dabei aber ganz geflissentlich, dass FTP *genau* für diese
Clientel das absolut falsche Produkt/Lösung ist.

Vorschläge (siehe auch Antwort an Rudolf)?

Ich kenne die Anforderungen nicht. SSH/SCP vielleicht? Oder Netstorage?

CU,

[Olaf Erkens]

Hallo Rudolf,

Post by Rudolf Thilo
Das einzige, was ich nicht verstehe ist, *WARUM* in Gottes Namen
*MÜSSEN* die Mausschubser diese Dateien per FTP bewegen?

Weil sie Notebooks haben und in der Weltgeschichte rumgondeln und
leider nicht immer an Stellen ins Internet gehen, wo ich die Funktion
anderer Möglichkeiten als sicher annehmen darf bzw. die "Dicke" der
Internetleitungen hinreichend ist. Oder weil sie irgendwo in der Welt
an einem dort installierten und konfigurierten Rechner sitzen und mal
eben eine Datei runter/hoch laden wollen.

Post by Rudolf Thilo
IMHO ist FTP aus diversen Gründen grundsätzlich für Mausschubser wenig
ideal ;)

Grundsätzlich ginge sicherlich der Remote Manager (zu dem ich auch
noch Fragen habe, aber da mach ich einen anderen Thread auf), nur ist
das Look&Feel eher nicht das eines Dateimanagers, mal ganz zu
schweigen von Drag&Drop bzw. Cut&Paste.

Post by Rudolf Thilo
FTP stammt aus der Dinosaurier-Zeit, und das bringt eben
Einschränkungen mit sich.

Ich geb dir ja grundsätzlich recht, wobei die Einschränkungen eben
umgehbar wären, wenn man den RFC von 1999 mal umgesetzt hätte.

Post by Rudolf Thilo
Es gibt ja genügend Alternativen, Dateien anders zu (maus)schubsen.

Die wären (außer Webdav ... da hatten wir bisher leider keine Zeit
für)?

Viele Grüße

Olaf

[Rudolf Thilo]

Post by Olaf Erkens
Hallo Rudolf,

Das einzige, was ich nicht verstehe ist, WARUM in Gottes Namen
MÜSSEN die Mausschubser diese Dateien per FTP bewegen?

Weil sie Notebooks haben und in der Weltgeschichte rumgondeln und
leider nicht immer an Stellen ins Internet gehen, wo ich die Funktion
anderer Möglichkeiten als sicher

Sicher?? Wenn Du's sicher haben willst, dann ist FTP das falshce
Protokoll. Wenn die mit ihrem Laptop in der Weltgeschichte umher
gondeln, dann kanst Du auf diese Laptops drauf installieren, was du
möchtest - oder vielleicht doch nicht ... ?


Schönen Gruß, Rudi.