Mit diesem Problem bin ich schon ein paar Mal in unpassenden Momenten konfrontiert worden:
Warum gibt es diese Grenze?
Warum ist sie noch nicht entfernt worden?
Wie gehen Sie mit der Wegbegrenzung um? Und nein, ein Wechsel zu Linux oder Mac OS X ist keine gültige Antwort auf diese Frage ;)
Ich zitiere diesen Artikel https://docs.microsoft.com/en-us/Windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation
Begrenzung der maximalen Trassenlänge
In der Windows-API (mit einigen Ausnahmen, die in den folgenden Abschnitten erörtert werden) ist die maximale Länge für einen Pfad MAX_PATH die auf 260 Zeichen festgelegt ist. Ein lokaler Pfad ist in der folgenden Reihenfolge aufgebaut: Laufwerksbuchstabe, Doppelpunkt, Backslash, durch Backslashes getrennte Namensbestandteile und ein abschließendes Nullzeichen. Der maximale Pfad auf Laufwerk D ist zum Beispiel "D:\ eine 256-stellige Pfadzeichenfolge <NUL>", wobei "<NUL>" das unsichtbare abschließende Nullzeichen für die aktuelle System-Codepage darstellt. (Die Zeichen < > werden hier aus Gründen der Übersichtlichkeit verwendet und können nicht Teil einer gültigen Pfadzeichenfolge sein).
Jetzt sehen wir, dass es 1+2+256+1 oder [Laufwerk][:\][Pfad][null] = 260 ist. Man könnte annehmen, dass 256 eine vernünftige feste Stringlänge aus den DOS-Tagen ist. Und wenn wir zu den DOS-APIs zurückgehen, stellen wir fest, dass das System den aktuellen Pfad pro Laufwerk verfolgte, und wir haben 26 (32 mit Symbolen) maximale Laufwerke (und aktuelle Verzeichnisse).
Im INT 0x21 AH=0x47 steht: "Diese Funktion liefert die Pfadbeschreibung ohne den Laufwerksbuchstaben und den anfänglichen Backslash." Wir sehen also, dass das System den CWD als Paar (Laufwerk, Pfad) speichert und Sie den Pfad durch Angabe des Laufwerks abfragen (1=A, 2=B, ), wenn Sie eine 0 angeben, wird der Pfad für das von INT 0x21 AH=0x15 AL=0x19 zurückgegebene Laufwerk angenommen. Jetzt wissen wir also, warum es 260 und nicht 256 ist, weil diese 4 Bytes nicht im Pfadstring gespeichert sind.
Warum ein 256-Byte-Pfad-String, weil 640K genug RAM ist.
Die Windows-API begrenzt die Länge, selbst im neuesten Betriebssystem. Microsoft hat Angst, Hunderte von Millionen von Betriebssystemen zu zerstören, wenn sich dies ändert, weil sie keine Genies mehr haben, die die API in- und auswendig kennen, wie sie es in den 1980er und 1990er Jahren taten. Das Risiko ist es nicht wert, es zu ändern. serverfault.com/questions/163419/
... es ist derselbe Grund, warum sie 64-Bit-Treiber im Ordner system32 und 32-Bit-Treiber im Ordner SysWOW64 speichern. Das Risiko, die ursprüngliche Windows-API zu brechen, könnte sie in den Bankrott treiben, weil ihre Entwickler sie nicht gut genug verstehen.
@MacGyver Tut mir leid, aber das ist völliger Blödsinn. Microsoft will die Millionen von schlecht geschriebenen Anwendungen da draußen nicht kaputt machen, die annehmen Dinge über das System, die nie garantiert waren. Leider waren die Dinge so lange gleich, dass sich die Entwickler auf sie verlassen haben, so dass eine Änderung jetzt die Anwendungen von Drittanbietern zerstören würde und MS die Schuld dafür bekommen würde.
Dies ist nicht unbedingt richtig, da das NTFS-Dateisystem Pfade mit bis zu 32k Zeichen unterstützt. Sie können die Win32-Api und " \\?\ " den Pfad vor, um mehr als 260 Zeichen zu verwenden.
Eine ausführliche Erklärung des langen Pfades aus der .Net BCL-Team-Blog .
Ein kleiner Auszug verdeutlicht das Problem der langen Wege
Ein weiteres Problem ist das inkonsistente Verhalten, das durch die Offenlegung der Unterstützung für lange Pfade entstehen würde. Lange Pfade mit dem
\\?\Präfix kann in den meisten dateibezogenen Windows-APIs verwendet werden, aber nicht in allen Windows-APIs. Zum Beispiel schlägt LoadLibrary, das ein Modul auf die Adresse des aufrufenden Prozesses abbildet, fehl, wenn der Dateiname länger als MAX_PATH ist. Das bedeutet, dass Sie mit MoveFile eine DLL an einen Ort verschieben können, an dem ihr Pfad länger als 260 Zeichen ist, aber wenn Sie versuchen, die DLL zu laden, würde dies fehlschlagen. Ähnliche Beispiele gibt es überall in den Windows-APIs; es gibt einige Umgehungsmöglichkeiten, die aber von Fall zu Fall unterschiedlich sind.
Gut und schön, aber das bedeutet, dass Sie P/Invoke an vielen Stellen verwenden müssen, und das schränkt meiner Meinung nach die Portabilität Ihres .Net-Codes ein. Was wäre, wenn ich die Mono-Kompatibilität beibehalten wollte?
Ich wollte damit sagen, dass man einen langen Weg benutzen kann, wenn man es wirklich will. Aber ich stimme zu, dass es ein Schmerz ist und persönlich würde ich dies auch vermeiden.
Dies sollte die gewählte Antwort sein. Sie beantwortet die vom Benutzer gestellte Frage, WARUM es diese Begrenzung gibt, und bietet eine Umgehungsmöglichkeit. Upvote für Sichtbarkeit
Die Frage lautet warum besteht die Einschränkung weiterhin. Sicherlich kann modernes Windows die Seite von MAX_PATH um längere Pfade zu ermöglichen. Warum wurde diese Beschränkung nicht aufgehoben?
Durch einen API-Vertrag hat Windows allen Anwendungen garantiert, dass die Standard-APIs für Dateien niemals einen Pfad zurückgeben, der länger als 260 Zeichen.
Bedenken Sie Folgendes richtig Code:
WIN32_FIND_DATA findData;
FindFirstFile("C:\Contoso\*", ref findData);Windows garantiert mein Programm, dass es meine Daten in die WIN32_FIND_DATA Struktur:
WIN32_FIND_DATA {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
//...
TCHAR cFileName[MAX_PATH];
//..
}Meine Anwendung hat den Wert der Konstante nicht deklariert MAX_PATH die Windows-API hat. Meine Anwendung verwendet diesen definierten Wert.
Meine Struktur ist korrekt definiert und ordnet nur 592 Bytes insgesamt. Das bedeutet, dass ich nur einen Dateinamen empfangen kann, der kleiner ist als 260 Zeichen. Windows versprochen Ich habe mir gesagt, wenn ich meine Bewerbung richtig schreibe, wird sie auch in Zukunft funktionieren.
Wenn Windows Dateinamen zulassen würde, die länger als 260 Zeichen, dann würde meine bestehende Anwendung (die die richtige API korrekt verwendet) fehlschlagen.
Für alle, die Microsoft auffordern, die MAX_PATH Konstante, müssen sie zunächst sicherstellen, dass keine bestehende Anwendung ausfällt. Ich besitze und verwende zum Beispiel immer noch eine Windows-Anwendung, die für Windows 3.11 geschrieben wurde. Sie läuft immer noch unter 64-Bit-Windows 10. Das ist es, was Abwärtskompatibilität ausmacht.
Microsoft hat eine Möglichkeit zu schaffen, die vollen 32.768 Pfadnamen zu verwenden; dafür mussten sie jedoch einen neuen API-Vertrag erstellen. Zum einen sollten Sie die Shell-API zum Aufzählen von Dateien (da nicht alle Dateien auf einer Festplatte oder Netzwerkfreigabe vorhanden sind).
Sie dürfen aber auch nicht die bestehenden Anwendungen der Benutzer beeinträchtigen. Die große Mehrheit der Anwendungen hat no die Shell-API für die Arbeit mit Dateien verwenden. Jeder ruft einfach FindFirstFile / FindNextFile und macht Schluss für heute.
Könnte Windows nicht lange Pfade transparent in kürzere Pfade übersetzen, um die Abwärtskompatibilität zu gewährleisten? Ich glaube, Windows 9x hat so etwas für die DOS-Kompatibilität getan.
@JosiahKeller Wenn dies der Fall wäre, würde es den ursprünglich für diese Methode definierten Vertrag brechen, und dies könnte unbeabsichtigten Speicher überschreiben und möglicherweise eine Sicherheitslücke öffnen. Die einzige Möglichkeit, dies zu beheben, besteht darin, eine neue, verbesserte API anzubieten (wie die Unicode-kompatiblen Varianten), und Hoffnung Jeder kompiliert seine Anwendungen neu und veröffentlicht sie unter Verwendung der neueren API.
@RowlandShaw Zum Glück Microsoft hat eine neue API erstellen, die lange Dateinamen unterstützt.
Unter Windows 10. können Sie die Beschränkung aufheben durch Ändern eines Registrierungsschlüssels.
Tipp Ab Windows 10, Version 1607, wurden die MAX_PATH-Beschränkungen von allgemeinen Win32-Datei- und Verzeichnisfunktionen entfernt. Sie müssen sich jedoch für das neue Verhalten entscheiden.
Mit einem Registrierungsschlüssel können Sie das neue Verhalten bei langen Pfaden aktivieren oder deaktivieren. Um das Verhalten bei langen Pfaden zu aktivieren, setzen Sie den Registrierungsschlüssel auf
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Typ:REG_DWORD). Der Wert des Schlüssels wird vom System (pro Prozess) nach dem ersten Aufruf einer betroffenen Win32-Datei- oder Verzeichnisfunktion zwischengespeichert (Liste folgt). Der Registrierungsschlüssel wird während der Lebensdauer des Prozesses nicht neu geladen. Damit alle Anwendungen auf dem System den Wert des Schlüssels erkennen, kann ein Neustart erforderlich sein, da einige Prozesse möglicherweise gestartet wurden, bevor der Schlüssel festgelegt wurde. Der Registrierungsschlüssel kann auch über die Gruppenrichtlinie gesteuert werden unterComputer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Sie können das neue Verhalten für lange Pfade auch pro App über das Manifest aktivieren:<application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"> <ws2:longPathAware>true</ws2:longPathAware> </windowsSettings> </application>
Leider hat der Datei-Explorer selbst in der neuesten Version von Win10 immer noch Probleme mit langen Pfadnamen. Selbst "Als Pfad kopieren" im Kontextmenü funktioniert nicht wie erwartet; es werden nur die ersten 260 Zeichen kopiert. Man kann keine Ordner erstellen, Dateien kopieren/verschieben/öffnen... Ich frage mich, was der Sinn dieser Änderung ist.
Beachten Sie, dass die Behauptung, die Systemeinstellung sei unabhängig von der Manifesteinstellung, falsch ist. Beide sind erforderlich. Die Richtlinie muss auf Systemebene aktiviert werden, und im Manifest muss angegeben werden, dass die Anwendung Long-Path-Aware ist.
Ich habe gelesen, dass diese Änderung zu Kompatibilitätsproblemen mit älteren 32-Bit-Anwendungen führen kann, aber ist diese Art von Kompatibilitätsproblem üblich? Ich würde die Änderung gerne selbst vornehmen. lifehacker.com/
Dies muss von einer Administrator-Eingabeaufforderung (mit erweiterten Rechten) ausgeführt werden.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
9 Stimmen
@Artelius: Tatsächlich unterstützt Windows (zumindest ab Win2K) Kreuzungspunkte ( de.wikipedia.org/wiki/NTFS_Junction_point ), und ab Vista werden symbolische NT-Verknüpfungen ( de.wikipedia.org/wiki/NTFS_symbolischer_link ). Wie auch immer, während Symlinks helfen können, längere/verschachtelte Pfade freundlicher zu gestalten, kann ich mir nicht vorstellen, wie Symlinks helfen würden, wenn man an die Grenzen der Pfadlänge stößt.
1 Stimmen
Auf meinem Windows 8 PC scheint die Grenze bei etwa 1024 Zeichen zu liegen, also YMMV.
10 Stimmen
Selbst wenn es diese Grenze nicht gäbe, gibt es immer noch viele andere Grenzen, und jede von ihnen könnte irgendwann lästig werden. Der Punkt ist, warum ist diese Grenze so niedrig? Nach der Ära von 8.3 und mit Mega-/Giga-Hardware sollte ein Pfad nun ein dynamisch zugewiesener String mit einer praktisch unbegrenzten Größe sein.
2 Stimmen
Bewältigung: Die Windows-Fehlermeldungen könnten besser sein. Ich habe gerade die Fehlermeldung "cannot find file..." (zweimal), als ich versuchte, eine Excel-Tabelle in einem langen Verzeichnis zu öffnen, nachdem ich eine Zip-Datei in meinem Downloads-Verzeichnis entpackt hatte. Die Fehlermeldung sollte sich eher darauf beziehen, dass versucht wird, einen Pfad zu verwenden, der MAX_PATH überschreitet, oder sie sollte einen abgeschnittenen Dateinamen anzeigen, anstatt den gesamten zu langen Namen.
17 Stimmen
Microsoft hat dieses Problem in Windows 10 Build 14352 endlich in Angriff genommen.
0 Stimmen
@WarrenP Sie meinen dies? stackoverflow.com/q/27680647/1157054
3 Stimmen
Ja, und es sieht so aus, als müssten Sie das App-Manifest ändern, damit es den langen Pfad erkennt.
3 Stimmen
@PatrickSzalapski leider wurde es behoben visualstudio.uservoice.com/forums/121579-visual-studio/
2 Stimmen
Mit dem \\ ?\ Präfix konnten wir bereits 32k lange Pfade verwenden, wahrscheinlich seit NT3.5
2 Stimmen
@WarrenP Leider hat Microsoft die Windows Explorer UI App nie aktualisiert, so dass das Problem auch heute noch im Jahr 2022 besteht.
1 Stimmen
@v.oddou Verwendung des \\ ?\ funktioniert auch nicht, da die Windows Explorer App sie vor dem Aufruf der älteren WIN32 API, die sie zum Aufzählen von Ordnern oder Öffnen von Dateien verwendet, entfernt.