| |
VB.NET - Ein- und UmsteigerLange Dateinamen behandeln in VB.NET | | | Autor: Schü | Datum: 07.11.18 18:20 |
| Hallo!
Ich suche mich gerade durch Google und bin nicht weiter gekommen.
Ich arbeite an einem Programm, dass Backups auf andere Platten machen soll.
Leider gibt es hin und wieder das Problem mit zu langen Pfaden oder Datei/Pfad Kombinationen.
Ich nutze NET-Framework 4.7.2 und das FileInfo-Objekt im IO.Namespace mit
...FileInfo.CopyTo(sFullPathZ, True) offenbar sollte das Problem laut Recherche ab NET 4.6.2 laut
https://docs.microsoft.com/de-de/dotnet/api/system.io.pathtoolongexception?view=netframework-4.7.2
gar nicht mehr existieren, aber bei mir wird trotzdem eine Ex gefeuert.
Wie gehe ich denn am besten mit einer Datei um, die, sagen wir auf einem Netzwerkpfad mit langem Pfadnamen liegt
und auch noch an eine anderer Stelle kopiert werden soll, die sogar insges. noch länger wäre?
Sicher stellt das aktuelle NET-Framework doch eine Funktion bereit, um die (ja bereits vorhandenen) zu langen
Dateien zu kopieren???
Schü | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: effeff | Datum: 08.11.18 11:05 |
| Besteht für Dich nicht die Möglichkeit, innerhalb der langen Pfadnamen eine Share einzurichten, um die Pfadnamen damit abkürzen zu können oder zumindest mit "subst" (Kommandozeile) den Pfaden Laufwerksbuchstaben zuzuweisen?
EALA FREYA FRESENA | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Schü | Datum: 08.11.18 11:18 |
| Hallo.
könntest Du das evtl. noch näher erläutern, was Du meinst?
Ich habe als Grundlage eine Liste mit Dictionary(Of String, FileInfo)-Objekten, wobei der Schlüssel der
vollständige Pfadname inkl. Dateiname ist.
Vor dem Kopieren muss der Zielpfad noch angepasst werden z.B. anderes Unterverzeichnis bzw. anderes LW.
Ich müsste bei jedem Key, der länger als 255 Zeichen ist ein Share einrichten?
Dabei ist zu bedenken, dass die Kombination mit dem Dateinamen maßgebend ist (der Pfad kann ja korrekte Länge haben..)
Davon mal abgesehen, wie ich dieses Share einrichte müsste ...
Wie machen das andere Programme? greifen die auf API zurück?
Schü | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: effeff | Datum: 08.11.18 17:36 |
| Eine Share richtet man nur einmal ein. Du bräuchtest zwei: Eine für den Quell- und eine für den Zielpfad.
Beispiel: Du hast den folgenden Pfad:
d:\irgendwas\nochwas\zumdrittenwas\quartalswas\quintettwas\sechtettpfad\siebterhimmelpfad\rettetmich
Für diesen Pfad erstellst Du nun die Share "Rettmichpfad" und kannst dann über \\Rechnername\Rettmichpfad darauf zugreifen.
Oder Du richtest mit subst eine Substitution ein für einen Pfad. Du würdest mit dem Befehl
subst f: d:\irgendwas\nochwas\zumdrittenwas\quartalswas\quintettwas\sechtettpfad\siebterhimmelpfad\rettetmich
den langen Pfad zum Laufwerksbuchstaben "f" zuweisen und könntest nun darüber auf die Dateien zugreifen.
EALA FREYA FRESENA | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Schü | Datum: 09.11.18 07:40 |
| OK.
verstehe.
Gibt es noch eine Alternative dazu?
Ich denke da an die API und die Unicode-Varianten.
Ein Programm z.B. in C++ müsste ja auch ohne Share das zu Stande bringen?
Und warum steht oben im Link, dass am NET-Framework > 4.6.2 lange Dateinamen explicit unterstützt werden?
Das sharen der Pfade ist sicher eine Möglichkeit, aber ich glaube nicht, dass dies die
einzige Alternative dazu wäre. | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Franki | Datum: 10.11.18 04:05 |
| Hallo,
mal eine Gegenfrage:
Warum brauchst du solche (zu langen) Pfade überhaupt?
Das ist ja für die User in beiden Richtunge völlig unübersichtlich wenn sie eine der Datien per Windows Explorer aufrufen möchten (egal ob alt oder neu)
Wenn das einen anderen Grund hat und die ganzen Unternamen irgendwelche Bedeutungen haben, dann solltest du über eine Datenbank nachdenken, Da hast du mehr Möglichkeiten die Daten zu unterscheiden als über Verzeichnisse / Ordner.
Zu konkretem Code kann ich dir nichts sagen, da ich noch vor diesem Problem stand. Ich programmiere seit es die 8.3 Regel gab und auch da war das machbar auf die gewünschten Dateien in der eigenen Software zugrifen zu können, egal ob sie auf einem Netzlaufwerk lagen oder lokal.
Wenn in der DB die Informationen zu z.B. Artikelnummer 4711 stehen, dann baucht der Artikel nicht in Aritelnummer/Warengruppe/langext/Kurztext/Lierferant/usw./usw./ ... zu stehen. Das wurde damals schon unübersichtlich und ist es wie man an deinem Beispiel sieht auch heute noch.
Selbst wenn Windows XXX die Gerenze erweitern würde, du würdest auch wieder an die Grenze kommen. Also beschreibe mal warum do solche Pfade brauchst...
Gruß
Frank | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Kuno60 | Datum: 10.11.18 12:21 |
| Hallo,
auf Windows 10 und ab FW 4.6.2 gibt es die Unterstützung für lange Pfade.
Es geht aber nur mit dem Prefix: "\\?\" vor jedem Pfad.
Trotzdem ist es besser lange Pfade zu vermeiden, da einige Programme (auch Windows) nicht mit langen Pfaden zurecht kommen.
Im Explorer ist es zwar möglich, Dateien in einen Ordner mit langem Pfad zu kopieren, aber man kann in diesem Ordner keine Dateien umbenennen und auch keine weiteren Ordner anlegen.
Im Framework sind schon ein paar neue Dinge eingebaut, die von Windows noch gar nicht unterstützt werden. | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Schü | Datum: 11.11.18 11:33 |
| Hallo.
zunächst: Ich nutze das Programm auf verschiedenen Betriebssystemen, je nach Rechner, hauptsächlich mit Windows 8.1 aber auch auf Win 10.
Ich kann daher nicht ausschließen, dass es sich um eine Kombination Win 8.1 mit NET 4.7.2 handelt.
Die Ordnerstruktur ist aber vorgegeben (Externe Platte). Diese hat nun mal dummerweise ein paar so lange Pfade.
Zwar nicht viele davon, aber im Programm reicht ja nun mal ein Treffer.
Windows stört das im übrigen gar nicht. Auch nicht auf Win 8.1!
Da das Backup ja vollständig sein soll, muss ergo auch alles exakt kopiert werden.
Da die Platte auf andere Verzeichnisse bzw. auf ein anderes Laufwerk mit eigener Unterstruktur "gespiegelt" werden soll, ergeben sich nun aus der Kombination mit dem neuen Ziel zusätzliche lange Pfade. Ist nun mal so.
Andere Programme können das ja auch. Nur nutzen die sicher andere Algo's bzw. API | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Franki | Datum: 12.11.18 02:42 |
| Hallo,
ok, mag sein, dass andere Programme das können (wie gut weiß man ja auch nicht wenn noch kein Fehler aufgetreten ist)
Und da du ja verschiedene Betriebssysteme nutzt würde ich auf Nummer Sicher gehen und versuchen die zu langen Dateinamen(Ordner) irgendwie zu ändern. Jeder Tipp den du jetzt hier evtl. erhälst und er auch funktioniert kann schon bei der nächsten Version wieder hinfällig sein und du fängst von vorne an mit diesem Problem.
Und was die User deiner Anwendung so haben an Umgebung kannst du auch nicht wissen, deshalb besser auf Nummer Sicher gehen und sich an die Basics halten.
Gruß
Frank | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Schü | Datum: 12.11.18 09:04 |
| Ok. Das könnte man versuchen, hinsichtlich eines Programms, was andere User nutzen (sollen).
Hier geht es um mein Programm, was für meine Zwecke konzipiert ist und gar nicht veröffentlicht werden soll. Es soll nur mein Problem lösen.
Sollte das evtl. bei späteren Betriebssystemen zu weiteren Anpassungen führen, muss ich eben anpassen.
Ich möchte nur die möglichen Lösung erörtern, die dort hin führen. Du meinst es sicherlich gut, wenn ich das Problem umgehen soll und die Struktur der Ordner anpasse, was ich nicht kann, damit wäre zwar scheinbar das Problem gelöst, aber an der Problemlösung ist nichts erreicht.
Der Ansatz von effeff wäre sicher möglich, aber mir noch zu aufwändig. Ich dachte da an die Nutzung der API?
Scheinbar will keiner mehr dahin zurück. Es wundert mich aber, dass Microsoft selbst eine Ordnerstruktur zulässt, die von MAXPATH abweicht, aber im Framework damit überhaupt nicht umgegangen werden kann.
Schü | |
Re: Lange Dateinamen behandeln in VB.NET | | | Autor: Franki | Datum: 13.11.18 03:40 |
| Hallo,
na ja, MS war in der Vergangenheit auch nicht immer konsequent, egal in welchem Bereich.
BS/Programmiersprache/API/und jetzt Framework/Core ist halt unterschiedlich, damit muss man sich abfinden, da wird sich wahrscheinlich in Zukunft auch nicht wirklich etwas ändern. Man muss sich halt das raus suchen was für die eigenen Bedürfnisse passt.
Gruß
Frank | |
| Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
Einloggen | Neu registrieren |
|
|
Neu! sevDTA 3.0 Pro
SEPA mit Kontonummernprüfung
Erstellen von SEPA-Dateien mit integriertem BIC-Verzeichnis und Konto- nummern-Prüfverfahren, so dass ungültige Bankdaten bereits im Vorfeld ermittelt werden können. Weitere InfosTipp des Monats März 2024 Dieter OtterUTF-8 Konvertierung von Dateien und StringsVB6 selbst verfügt über keine Funktionen zur UTF-8 Konvertierung von Daten. Mit Hilfe des ADODB.Stream-Objekts lassen sich diese fehlenden Funktionen aber schnell nachrüsten. Access-Tools Vol.1
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|