MAX_PATH Einschränkung in Boost.Filesystem

Question

Ich möchte Boost.Filesystem Bibliothek verwenden Pfade, Dateien und Verzeichnisse zu manipulieren. Meine Frage ist, sind Wege länger als MAX_PATH unterstützt?

Ich weiß, dass in Win32API haben wir Abhilfe „\\? \“, Aber es ist nicht von Grundfunktionen wie PathAppend und PathCombine unterstützt.

Also ich bin für jede nützliche Informationen über MAX_PATH und Boost.FS suchen.

Danke

UPD: Ich kümmere mich um alle Betriebe wie Pfad append, Pfad verbinden, etc. (Ich habe diese Funktionen in Win32API, aber sie funktioniert nicht mit Pfaden länger als MAX_PATH) Zum Beispiel CreateFileW und DeleteFileW beide Stützwege länger als MAX_PATH. Kann Boost.FS ein Ersatz für Funktionen Win32API Nutzen sein, wie nicht gefunden lange Wege

unterstützen diejenigen, die in shlwapi und shell32, die oft

Answer 1

Die Wahrheit ist, dass Windows-Pfade beliebiger Länge unterstützt, und jeder Pfad kann auf Windows-String umgewandelt werden. Hinzufügen \\?\ ist in diesem Fall erforderlich, aber das ist der Teil von „einen String macht aus einem bestimmten Pfad“ -Betrieb.

AFAIK, boost :: filesystem tut dies falsch auf Windows.

Ich weiß nicht, ob ein Update geplant ist. Siehe diese darüber, wie es sein sollte getan.

Answer 2

Sie können mit oder ohne Boost.Filesystem eine beliebige Länge von Dateisystempfad Zeichenfolge bearbeiten.

MAX_PATH sind die Einschränkungen von Windows File APIs. Das heißt, man kann nicht zu lange Pfadzeichenfolge zu Windows-APIs übergeben.

Zum Beispiel Entfernen Funktion des Boost.Filesystem wird mit länger ausfallen als MAX_PATH Länge Pfad. Sie wollen Boost.Filesystem so etwas wie ändern aktuelles Verzeichnis zu tun und benutzen relativen Pfad zu Verhindern, dass MAX_PATH Einschränkung? Ich glaube nicht, so ist es möglich.

EDITED

Da Boost.Filesystem auf C ++ String implementiert, haben Sie Grund zur Sorge Pfadlänge nicht brauchen. Boost.Filesystem bietet nicht nur Methoden String-Manipulation Weg, sondern auch Methoden System Manipulation Datei. Sie sollten Dateisystem Methoden vermeiden, wenn der resultierende Pfad zu lang ist.

Ich weiß nicht, ob Boost.Filesystem Support-Pfad Win32 Unicode, aber man konnte letzte ANSI Pfad zu Unicode-Pfad konvertieren, bevor Win32-Datei-APIs aufrufen.