Warum gibt es in Windows die Pfadlängenbeschränkung von 260 Zeichen?

Ich bin in ungünstigen Momenten einige Male auf dieses Problem gestoßen:

• Der Versuch, an Open Source-Java-Projekten mit tiefen Pfaden zu arbeiten
• Speichern von tiefen Fitnesse-Wiki-Bäumen in der Quellcodeverwaltung
• Ein Fehler beim Versuch, Bazaar zum Importieren meines Versionsverwaltungsbaums zu verwenden

Warum gibt es diese Grenze?

Warum wurde es noch nicht entfernt?

Wie gehen Sie mit der Pfadbegrenzung um? Und nein, ein Wechsel zu Linux oder Mac OS X ist keine gültige Antwort auf diese Frage;)

Zitieren dieses Artikels https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Maximale Pfadlängenbeschränkung

In der Windows-API (mit einigen Ausnahmen, die in den folgenden Abschnitten erläutert werden) beträgt die maximale Länge für einen Pfad MAX_PATH , der als 260 Zeichen definiert ist. Ein lokaler Pfad ist in der folgenden Reihenfolge strukturiert: Laufwerksbuchstabe, Doppelpunkt, Backslash, durch Backslashes getrennte Namenskomponenten und ein abschließendes Nullzeichen. Der maximale Pfad auf Laufwerk D lautet beispielsweise "D: \ eine Pfadzeichenfolge mit 256 Zeichen <NUL>", wobei "<NUL>" das unsichtbare abschließende Nullzeichen für die aktuelle Systemcodepage darstellt. (Die Zeichen <> werden hier aus Gründen der visuellen Klarheit 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 Zeichenfolgenlänge aus den DOS-Tagen ist. Wenn wir zurück zu den DOS-APIs gehen, stellen wir fest, dass das System den aktuellen Pfad pro Laufwerk verfolgt hat und wir maximal 26 (32 mit Symbolen) Laufwerke (und aktuelle Verzeichnisse) haben.

Das INT 0x21 AH = 0x47 sagt: "Diese Funktion gibt die Pfadbeschreibung ohne den Laufwerksbuchstaben und den anfänglichen Backslash zurück." Wir sehen also, dass das System die CWD als Paar (Laufwerk, Pfad) speichert und Sie nach dem Pfad fragen, indem Sie das Laufwerk angeben (1 = A, 2 = B,…). Wenn Sie eine 0 angeben, nimmt es den Pfad für an Das von INT 0x21 AH = 0x15 AL = 0x19 zurückgegebene Laufwerk. Jetzt wissen wir also, warum es 260 und nicht 256 ist, weil diese 4 Bytes nicht in der Pfadzeichenfolge gespeichert sind.

Warum eine 256-Byte-Pfadzeichenfolge, weil 640 KB genug RAM sind.

Dies gilt nicht unbedingt, da das NTFS-Dateisystem Pfade mit bis zu 32.000 Zeichen unterstützt. Sie können die Win32-API und das \\?\Präfix " " verwenden, um mehr als 260 Zeichen zu verwenden.

Eine ausführliche Erklärung des langen Weges aus dem .Net BCL-Teamblog .
Ein kleiner Auszug beleuchtet das Problem mit langen Wegen

Ein weiteres Problem ist inkonsistentes Verhalten, das sich aus der Bereitstellung von Unterstützung für lange Pfade ergeben würde. Lange Pfade mit dem \\?\Präfix können in den meisten dateibezogenen Windows-APIs verwendet werden, jedoch nicht in allen Windows-APIs. Beispielsweise schlägt LoadLibrary, die ein Modul der Adresse des aufrufenden Prozesses zuordnet, fehl, wenn der Dateiname länger als MAX_PATH ist. Dies bedeutet, dass Sie mit MoveFile eine DLL an einen Ort verschieben können, an dem ihr Pfad länger als 260 Zeichen ist. Wenn Sie jedoch versuchen, die DLL zu laden, schlägt dies fehl. Es gibt ähnliche Beispiele in allen Windows-APIs. Es gibt einige Problemumgehungen, die jedoch von Fall zu Fall erfolgen.

Die Frage ist, warum die Einschränkung noch besteht. Sicherlich können moderne Windows die Seite vergrößern MAX_PATH, um längere Pfade zu ermöglichen. Warum wurde die Einschränkung nicht aufgehoben?

• Der Grund, warum es nicht entfernt werden kann, ist, dass Windows versprochen hat, dass es sich niemals ändern wird.

Durch den API-Vertrag hat Windows allen Anwendungen garantiert, dass die Standard-Datei-APIs niemals einen Pfad zurückgeben, der länger als 260Zeichen ist.

Betrachten Sie den folgenden korrekten Code:

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows garantierte meinem Programm, dass es meine WIN32_FIND_DATAStruktur füllen würde :

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 jedoch. Meine Anwendung hat diesen definierten Wert verwendet.

Meine Struktur ist korrekt definiert und weist nur die 592Gesamtzahl der Bytes zu. Das bedeutet, dass ich nur einen Dateinamen erhalten kann, der weniger als 260Zeichen enthält. Windows versprach mir, dass meine Anwendung auch in Zukunft funktionieren würde, wenn ich meine Anwendung richtig schreiben würde.

Wenn Windows Dateinamen länger als 260Zeichen zulässt, schlägt meine vorhandene Anwendung (die die richtige API korrekt verwendet hat) fehl.

Wenn Microsoft die MAX_PATHKonstante ändern soll , muss zunächst sichergestellt werden, dass keine vorhandene Anwendung fehlschlägt. Zum Beispiel besitze und verwende ich immer noch eine Windows-Anwendung, die für die Ausführung unter Windows 3.11 geschrieben wurde. Es läuft immer noch unter 64-Bit-Windows 10. Genau das bringt Ihnen die Abwärtskompatibilität.

Microsoft hat eine Möglichkeit geschaffen, die vollständigen 32.768 Pfadnamen zu verwenden. Dafür mussten sie jedoch einen neuen API-Vertrag erstellen. Zum einen sollten Sie die Shell-API verwenden, um Dateien aufzulisten (da nicht alle Dateien auf einer Festplatte oder einer Netzwerkfreigabe vorhanden sind).

Sie müssen aber auch vorhandene Benutzeranwendungen nicht beschädigen. Die überwiegende Mehrzahl der Anwendungen nicht nicht verwenden , um das Shell - api für Kleinarbeit. Jeder ruft einfach anFindFirstFile / an FindNextFileund nennt es einen Tag.

Unter Windows 10 können Sie die Einschränkung aufheben, indem Sie einen Registrierungsschlüssel ändern.

Tipp Ab Windows 10, Version 1607, wurden die MAX_PATH-Einschränkungen aus den allgemeinen Win32-Datei- und Verzeichnisfunktionen entfernt. Sie müssen sich jedoch für das neue Verhalten anmelden.

Mit einem Registrierungsschlüssel können Sie das neue Verhalten für lange Pfade 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 Apps auf dem System den Wert des Schlüssels erkennen können, ist möglicherweise ein Neustart erforderlich, da einige Prozesse möglicherweise vor dem Festlegen des Schlüssels gestartet wurden. Der Registrierungsschlüssel kann auch über Gruppenrichtlinien unter gesteuert werden Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Sie können das neue Verhalten für lange Pfade pro App auch ü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>

Sie können einen Ordner als Laufwerk bereitstellen. Wenn Sie über die Befehlszeile einen Pfad haben C:\path\to\long\folder, können Sie ihn dem Laufwerksbuchstaben zuordnen, X:indem Sie Folgendes verwenden:

subst x: \path\to\long\folder

Eine Möglichkeit, mit der Pfadbeschränkung umzugehen, besteht darin, Pfadeinträge mit symbolischen Links zu verkürzen.

Zum Beispiel:

1. Erstellen Sie ein C:\pVerzeichnis, um kurze Links zu langen Pfaden zu erhalten
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. Fügen Sie C:\p\fooIhrem Pfad anstelle des langen Pfads hinzu

Sie können lange Pfadnamen mit PowerShell aktivieren:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

Eine andere Version ist die Verwendung einer Gruppenrichtlinie in Computer Configuration/ Administrative Templates/ System/ Filesystem:

Was , warum dies noch existiert - MS halte es für keine Priorität, und die Werte der Abwärtskompatibilität über ihre OS fort (zumindest in diesem Fall).

Eine Problemumgehung, die ich verwende, besteht darin, die "Kurznamen" für die Verzeichnisse im Pfad anstelle ihrer für Menschen lesbaren Standardversionen zu verwenden. Also zB für C:\Program Files\ich würde verwenden C:\PROGRA~1\ Sie können die Kurznamenäquivalente mit finden dir /x.

Informationen zum Umgang mit der Pfadgrößenbeschränkung unter Windows: Die Verwendung von 7zip zum Packen (und Entpacken) Ihrer pfadlängensensitiven Dateien scheint eine praktikable Problemumgehung zu sein. Ich habe es verwendet, um mehrere IDE-Installationen (diese Eclipse-Plugin-Pfade, Huch!) Und Stapel automatisch generierter Dokumentation zu transportieren, und hatte bisher kein einziges Problem.

Ich bin mir nicht sicher, wie es das von Windows festgelegte Limit von 260 Zeichen (von einem technischen PoV) umgeht, aber hey, es funktioniert!

Weitere Details auf ihrer SourceForge-Seite hier :

"NTFS kann Pfadnamen mit einer Länge von bis zu 32.000 Zeichen unterstützen."

7-zip unterstützt auch so lange Namen.

Aber es ist im SFX-Code deaktiviert. Einige Benutzer mögen keine langen Pfade, da sie nicht verstehen, wie sie damit arbeiten sollen. Deshalb habe ich es im SFX-Code deaktiviert.

und Versionshinweise :

9.32 alpha 2013-12-01

• Verbesserte Unterstützung für Dateipfadnamen mit mehr als 260 Zeichen.

4.44 Beta 2007-01-20

• 7-Zip unterstützt jetzt Dateipfadnamen mit mehr als 260 Zeichen.

WICHTIGER HINWEIS: Damit dies ordnungsgemäß funktioniert, müssen Sie den Zielpfad im 7zip- Dialogfeld "Extrahieren" direkt angeben , anstatt die Dateien per Drag & Drop in den vorgesehenen Ordner zu ziehen. Andernfalls wird der Ordner "Temp" als Zwischencache verwendet und Sie werden in die gleiche Beschränkung von 260 Zeichen versetzt, sobald Windows Explorer beginnt, die Dateien an ihren "letzten Ruheplatz" zu verschieben. Weitere Informationen finden Sie in den Antworten auf diese Frage .

Dies ist der Fall, und aus irgendeinem Grund ist dies eine Standardeinstellung. Sie können sie jedoch mit diesem Registrierungsschlüssel leicht überschreiben:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Siehe: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Eine andere Möglichkeit, damit umzugehen, ist die Verwendung von Cygwin, je nachdem, was Sie mit den Dateien tun möchten (dh ob Cygwin-Befehle Ihren Anforderungen entsprechen).

Beispielsweise können Dateien kopiert, verschoben oder umbenannt werden, die selbst Windows Explorer nicht kann. Oder beschäftigen Sie sich natürlich mit deren Inhalten wie md5sum, grep, gzip usw.

Auch für Programme, die Sie codieren, können Sie sie mit der Cygwin-DLL verknüpfen und so lange Pfade verwenden (ich habe dies jedoch nicht getestet).