Lange Windows-Dateinamen
Zur Startseite     Tipps & Tricks     PC/GEOS-Rechner     Lange Windows-Dateinamen
 
Der hier beschriebene Treiber ist evtl. nicht mehr aktuell!

Es kann Situationen geben, in denen es hilfreich ist, auch unter DOS/GEOS Zugriff auf Dateien/Verzeichnisse mit langen Windows-Dateinamen zu haben. Es gibt mehrere entsprechende DOS-Treiber, der hier Angebotene ist vielleicht der am weitesten Fortgeschrittene, u.a. dürfte er der einzige sein, der deutsche Umlaute unterstützt. Ergänzend ist noch zu sagen, dass sich der Dateizugriff durch den Treiber verlangsamt.

Download DOSLFN.ZIP (d/e) - 291 KB

Download GEOSLFN.ZIP - 21 KB

Damit die langen Dateinamen auch unter GEOS erkannt werden, müssen beide Treiber installiert sein.


Die folgenden Texte stammen aus Newsgroups, Autoren sind Rainer B. und Jörg P.:

Ursprünglich stammt der Tipp von Steve Everett. Man macht folgendes:

  1. DOSLFN laden (kostet leider 12 bis 16 kb)
  2. in der GEOS.INI unter [system] primaryFSD = mslf.geo eintragen.
  3. GEOS starten

Leider schließt sich ms4.geo und mslf.geo gegenseitig aus, dh. mslf.geo läuft ohne DOSLFN-Treiber nicht. Ob es andersrum (ms4.geo mit DOSLFN) geht weiss ich jetzt nicht. fs = mslf.geo crasht auch.

Seiteneffekt ist, dass mit geladenem mslf.geo keine @dirnames mehr angelegt werden. Limit ist, dass nur Dateinamen bis 32 Zeichen lang angezeigt werden. Sind die Dateinamen länger, liefert der Treiber wieder die kurzen Dateinamen - sonst würde wohl auch jede Software crashen ;-)

Rainer


Nachdem ja schon einige andere GEOS-User davon berichtet haben, mit dem GlobalPC-Treiber "mslf.geo" auch auf einem "normalen" PC unter Win95/98/98SE die langen "Windowsdateinamen" nutzen zu können, habe ich das gestern auch mal probiert. Ergebnisse:

  • Je nach GEOS-Version muss man den Treiber mal mittels "fs =" und mal mittels "primaryFSD = " einbinden. Erwischt man den falschen GEOS.INI-Eintrag, stürzt GEOS beim Starten ab.
  • In der DOS-Box von Windows ME habe ich das ganze "nur lesend" zum Laufen bekommen: Ich kann zwar bestehende Dateien ändern, löschen, umbenennen (und zum Teil auch kopieren), aber keine neuen Dateien anlegen. (Ob das nun am MS-DOS 8.0 von WinME (Win95/98/98SE nutzen ein MS-DOS 7.x) liegt, oder an meinem Virenscanner oder oder oder, kann ich noch nicht sagen. (Verzeichnisse konnte ich übrigens trotzdem erstellen.)
Da das Ganze trotzdem "irgendwie" lief, hier nun meine Kurzkritik:

Erster Eindruck: Genial.

Zweiter Eindruck: Uhoh!

Pro:

  • Es funktioniert! Alle "Windowsdateinamen", die nicht länger als ein langer GEOS-Dateiname (32 Zeichen) sind, werden korrekt dargestellt. Alle längeren Dateien werden mit dem DOS-Dateinamen (also BLABLA~1.TXT oder so) angezeigt. Dadurch bleibt GEOS kompatibel. (Und um ehrlich zu sein, sind noch längere Dateinamen auf einer normalen Windowsfestplatte extrem selten ;-)
Contra:

  • Dateinamen, die länger als 32 Zeichen sind, werden trotzdem nur in der DOS-Kurzform dargestellt. Das ist zwar kompatibel, aber in der Nutzung "unschön", da man nie weiß, ob sich z.B. eine unter Windows heruntergeladene HTML-Dokumentation in Gänze unter GEOS nutzen läßt. Zudem ist es so bei Dateinamen mit einer Tilde (~) unklar, ob die Datei nun "absichtlich" so heißt, oder einfach von GEOS verkürzt wurde.
  • Nach dem Umstellen von ms4.geo auf mslf.geo (und umgedreht), behauptet z.B. NewDesk, dass es kein Laufwerk C: mehr gäbe, und schließt alle Fenster. Man kann dann zwar alle Fenster wieder ohne Probleme öffnen, aber trotzdem ist vor dem Wechsel sicherzustellen, dass wirklich alle GEOS-Programme beendet wurden. Insbesondere ist es wichtig, keine Dateien mehr mit GeoWrite oder so geöffnet zu haben!
  • Legt man mit mslf.geo z.B. ein Verzeichnis namens "WebPhoto" an, bekommt dieses Verzeichnis korrekt den Windowsnamen "WebPhoto", der auch von allen GEOS-Programmen so genutzt werden kann. Es wird jedoch kein @dirname.000 erzeugt. Folge: Nutzt man wieder ms4.geo, heißt das Verzeichnis unter GEOS auf einmal "WEBPHOTO". Mein WebPhotos-Programm findet es daraufhin nicht mehr. Die "Rückwärtskompatibilität" ist also nicht so ganz gesichert!
  • Programme, die mit DOS-Dateien (DOS-Texte, DOS-Bilder, DOS-Musikdateien, ...) arbeiten, funktionieren nicht unbedingt mit den langen Dateinamen und können im Zweifel sogar abstürzen. Z.B. die "Duplicate"-Funktion vom GeoManager/NewManager erlaubt bei der Eingabe des neuen Namens nur das kurze DOS-"8.3"-Format. (Immerhin kann man das Ergebnis dann unter NewDesk mit einem langen Dateinamen versehen ;-)(Mehr dazu im Teil für die Programmierer.)
Für die Programmierer und alle, die es sonst interessieren könnte:

  • Nutzt man FileEnum zur Anzeige von DOS-Dateien, hat es vorher gereicht, für die gelieferten Namen ein Char[13] zu nutzen. (12 Zeichen für den max. DOS-Namen + 1 Zeichen für die abschließende Null.) Stößt FileEnum durch das mslf.geo nun auf längere Namen, bricht es mit einer Fehlermeldung und null gefundenen Dateien ab. Fängt man dieses nicht ab, gibt's Probleme.
  • Es ist unklar, wie lang die zurückgelieferten Dateinamen nun wirklich werden können. In der entsprechenden file-include-Datei gibt's dazu zwei Werte: 32 chars (als FileLongName oder so) und 36 chars (als FileLongNameBuffer oder so). Ich nutze sicherheitshalber 37, falls die Namen wirklich 36 chars lang werden können. (Schließlich muß ja noch eine abschließende Null an den String kommen können ;-)
  • Es gibt div. GEOS-Routinen, die mit einem DOS-Namen arbeiten. Der "JobStatus" beim Spooler enthält z.B. laut Doku auch einen 8.3-Dosnamen. Ob das schon umgestellt wurde? Und in welcher SDK-Version? Was viel schlimmer ist, sind die ganzen GenText-Attribute:

    ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,

    ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... .

    Funktionieren diese Sachen jetzt auch schon mit den langen Dateinamen?

  • Die eigenen Routinen funktionieren auch nicht unbedingt auf Anhieb, wenn man einfach nur den Namen von char[13] auf char[37] umstellt:

    Die Dateinamen dürfen jetzt z.B. auch Leerzeichen enthalten (Was meistens nicht so ein Problem darstellt, sollte man aber trotzdem mal durchspielen!)

    Die Dateinamen dürfen jetzt mehr als einen Punkt und nach dem Punkt auch mehr als 3 Zeichen haben. (Bei meinen Routinen in WebPhoto würden z.B. z.Zt. die Dateien "1.GIF", "1.GIF.TXT" und "1.GIFBlaSülz" alle als "1.GIF" erkannt und behandelt werden!)

    JPEG-Bilder können jetzt z.B. nicht mehr nur die Endungen .JPG und .JPE haben, sondern auch ".jPg". (Bei den eigenen Vergleichsroutinen für die Endungen also immer beide Strings in Groß- oder Kleinbuchstaben umwandeln!) und zudem nun auch noch ".jpeg"!

  • Es ist mir unklar, ob MyTurn/NewDeal/Breadbox nicht doch neuere SDKs einsetz(t)en, bei denen die korrekte Behandlung langer (Win)Do(w)s-Namen konsequenter umgesetzt und irgendwo vernünftig beschrieben wurde. Bislang beruht mein "Wissen" nur auf den Tests von Rainer Bettsteller und mir.
Fazit:

a) Wer's selber ausprobieren will, sollte erstmal auf einer Zweitinstallation arbeiten, da nicht unbedingt alle NDO2000-/BBE-Programme mit den langen Namen umgehen können (von den Programmen von Drittanbietern will ich erst gar nicht mal reden). Und ein "Rückstieg" auf die kurzen "8.3"-DOS-Namen ist wegen der Probleme mit neuen Verzeichnissen, ... nicht unbedingt ohne Weiteres möglich.

b) Bleibt man weg von Motif und dem GeoManager, funktionieren die langen Dateinamen unter NDO2000/BBE extrem gut. Lediglich die üblichen kleinen Zusatzprogramme fehlen noch ... (Rainer Bettsteller hat übrigens sein GeoZip und Gonzo schon umgestellt. Mein WebPhoto folgt in Kürze.)

Jörg
 

Zum Anfang der Seite     Zuletzt geändert 21.05.14 Mütze