Dateipfade konvertieren ins MS DOS-Format

[Puschkin 0]

Hallo,

 

kannn mir evtl. jemand ein VB-Script zur Verfügung stellen, mit dem überlange Dateipfade- mehr als 260 Zeichen-, in MS DOS-Format konvertiert werden?

 

[BOfH_666 568]

Hallo Puschkin,

 

wir liefern hier üblicherweise keinen gebrauchsfertigen Code auf Anfrage. Du wirst Dir schon selbst ein bissl Mühe geben müssen. Hast Du denn schon mal gesucht, ob Du was Passendes finden kannst. Meistens ist man ja nicht der Erste, der nach einer Lösung sucht.

 

Wofür brauchst Du denn überhaupt so etwas Altertümliches? 2020 sollten doch etwas längere Pfade kein Problem mehr sein.

[Puschkin 0]

vor 8 Minuten schrieb BOfH_666:

Hallo Puschkin,

 

wir liefern hier üblicherweise keinen gebrauchsfertigen Code auf Anfrage. Du wirst Dir schon selbst ein bissl Mühe geben müssen. Hast Du denn schon mal gesucht, ob Du was Passendes finden kannst. Meistens ist man ja nicht der Erste, der nach einer Lösung sucht.

 

Wofür brauchst Du denn überhaupt so etwas Altertümliches? 2020 sollten doch etwas längere Pfade kein Problem mehr sein.

Dank für die Nachfrage und die schnelle Reaktion. Ich habe das Thema aufgeschnappt und bin leider selbst schon lange raus. Es arbeitet jemand mit einem Programm, bei dem er mit dem Problem konfrontiert ist, dass es in Pfadstrukturen hineinwirkt, die länger als 260 Zeichen sind und dort zu Fehlern führt. Die Idee: Die Struktur samt Dokumenten kopieren in eine MS DOS- Pfadstruktur, damit das Programm dort normal wirkt.

Ich würde gern helfen und habe vor einigen Tagen dieses Forum hier entdeckt.

[Gu4rdi4n 53]

Ich lese jetzt heraus, dass er zwar mit einem Programm arbeitet, dass mit den langen Pfaden arbeitet, aber nicht, dass das Programm nicht generell mit Langen Pfaden umgehen kann?

 

Aktiviere doch mal testweise das hier:

https://www.windows-faq.de/2016/11/06/windows-10-ordnernamen-und-dateinamen-groesser-260-zeichen/

[Puschkin 0]

vor 4 Minuten schrieb Gu4rdi4n:

Ich lese jetzt heraus, dass er zwar mit einem Programm arbeitet, dass mit den langen Pfaden arbeitet, aber nicht, dass das Programm nicht generell mit Langen Pfaden umgehen kann?

 

Aktiviere doch mal testweise das hier:

https://www.windows-faq.de/2016/11/06/windows-10-ordnernamen-und-dateinamen-groesser-260-zeichen/

Auch hierfür ganz herzlichen Dank. Schon die zweite schnelle Reaktion.

 

Der Registry-Aspekt ist bekannt. Das ist nicht das Problem. Das Programm kann an sich mit langen Pfaden umgehen. Bestimmte Weiterverarbeitungen funktionieren nicht. Daher das Bemühen, die Pfadstruktur samt Dokumenten in eine MS-DOS-Pfadstruktur zu kopieren.

[NilsK 2.781]

Moin,

 

könntest du bitte noch mal erläutern, was du dir unter einer 

vor 2 Stunden schrieb Puschkin:

MS-DOS-Pfadstruktur

vorstellst?

 

Gruß, Nils

 

[Puschkin 0]

vor 15 Minuten schrieb NilsK:

Moin,

 

könntest du bitte noch mal erläutern, was du dir unter einer 

vorstellst?

 

Gruß, Nils

 

Dank für die Nachfrage.

 

Nun ja: Da sind Pfadstrukturen, die in ihrer Gesamtlänge 260 Zeichen übersteigen. Wenn man für jeden Unterpfad-Namen nur 8 Zeichen verwendet, könnte man eine Pfadstruktur mit 32 Unterverzeichnissen managen. Beispiel: Aus C:\Programme\Microsoft Office\Office10\WINWORD.EXE wird C:\PROGRA~1\MICROS~2\Office10\WINWORD.EXE.

 

Also ein Script, dass aus langen Dateipfaden den kurzen DOS- Pfad (8.3) ermittelt.

 

Wünsche noch einen schönen Abend.

[NilsK 2.781]

Moin,

 

oha. Ich wage energisch zu bezweifeln, dass du auf dem Weg irgendein sinnvolles Ziel erreichst. Ich verstehe den Ansatz, aber das wird nix. Schon deshalb nicht, weil du heutzutage nicht davon ausgehen kannst, dass zu jedem "langen" Namen tatsächlich ein 8.3-Name vorhanden ist. Schau dich einfach mal mit "dir /X" in einem CMD-Fenster in verschiedenen Ordnern um. 

 

Wenn wirklich eine Software beteiligt ist, die mit langen Pfaden nicht umgehen kann, dann ist der einzige sinnvolle Weg, die Pfade tatsächlich zu kürzen, d.h. die Daten in eine einfachere Struktur zu verschieben.

 

EDIT: Weil ich jetzt doch noch ein wenig rumgesucht habe, hier eine interessante Fundstelle dazu. Aber: du bist gewarnt. Für produktionsreif halte ich das nicht. Bei mir gibt es mehrere Volumes ohne Kurznamen.

https://devblogs.microsoft.com/scripting/use-powershell-to-display-short-file-and-folder-names/

 

Gruß, Nils

 

bearbeitet 25. Februar 2020 von NilsK

[Puschkin 0]

vor 17 Minuten schrieb NilsK:

Moin,

 

oha. Ich wage energisch zu bezweifeln, dass du auf dem Weg irgendein sinnvolles Ziel erreichst. Ich verstehe den Ansatz, aber das wird nix. Schon deshalb nicht, weil du heutzutage nicht davon ausgehen kannst, dass zu jedem "langen" Namen tatsächlich ein 8.3-Name vorhanden ist. Schau dich einfach mal mit "dir /X" in einem CMD-Fenster in verschiedenen Ordnern um. 

 

Wenn wirklich eine Software beteiligt ist, die mit langen Pfaden nicht umgehen kann, dann ist der einzige sinnvolle Weg, die Pfade tatsächlich zu kürzen, d.h. die Daten in eine einfachere Struktur zu verschieben.

 

EDIT: Weil ich jetzt doch noch ein wenig rumgesucht habe, hier eine interessante Fundstelle dazu. Aber: du bist gewarnt. Für produktionsreif halte ich das nicht. Bei mir gibt es mehrere Volumes ohne Kurznamen.

https://devblogs.microsoft.com/scripting/use-powershell-to-display-short-file-and-folder-names/

 

Gruß, Nils

 

Herzlichen Dank für Deinen betriebenen Aufwand, die Rückmeldung und den Link. Ich gebe das mal weiter. Mal schauen, ob hier noch was eingeht..

[mwiederkehr 351]

vor 1 Stunde schrieb NilsK:

Bei mir gibt es mehrere Volumes ohne Kurznamen.

Bei mir gibt es die Kurznamen nur auf C:, nicht auf den anderen Partitionen. Anscheinend erzeugen neuere Versionen von Windows die Namen nicht mehr automatisch: https://superuser.com/questions/1505174/how-comes-that-short-filenames-8-3-are-created-in-one-partition-and-not-in-ano

 

Nach der Aktivierung von 8.3-Namen werden diese für existierende Dateien nicht erzeugt. Man muss den Verzeichnisbaum mit Robocopy nach "_neu" kopieren und dann das alte Verzeichnis löschen und das neue umbenennen.

[magheinz 100]

Ich bilde mir auch ein das intern teilweise trotzdem mit den langen Namen gearbeitet wird was dann zu immer weniger durchschaubaren Fehlern führt. 

 

Was gehen müsste: einen mountpunkt mit einem Ziel tiefer Pfad und dann von dem aus arbeiten. Je nach Anforderungen kann das funktionieren. 

[NilsK 2.781]

Moin,

 

ja, man hat sowas früher oft mit SUBST "gelöst". Ist aber auch eher halbgar.

 

Gruß, Nils