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

390

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;)

Jeffrey Cameron
quelle
8
@Artelius: Tatsächlich unterstützt Windows (zumindest ab Win2K) Verbindungspunkte ( en.wikipedia.org/wiki/NTFS_junction_point ) und Vista ab NT symbolische NT-Links ( en.wikipedia.org/wiki/NTFS_symbolic_link ). Obwohl Symlinks dazu beitragen können, längere / verschachtelte Pfade benutzerfreundlicher zu gestalten, kann ich mir nicht vorstellen, wie Symlinks helfen würden, wenn Sie die Pfadlängenbeschränkungen erreichen.
Ashutosh Mehra
8
Selbst wenn diese Grenze nicht existiert hätte, gibt es immer viele andere Grenzen, und jede von ihnen könnte irgendwann ärgerlich sein. Der Punkt ist, warum ist diese Grenze so niedrig? Nach der Ära 8.3 und mit Hardware im Mega- / Giga-Format sollte ein Pfad nun eine dynamisch zugewiesene Zeichenfolge mit einer praktisch unbegrenzten Größe sein.
Roland
12
Microsoft behebt dieses Problem endlich in Windows 10 Build 14352.
Warren P
3
Ja, und es sieht so aus, als müssten Sie das App-Manifest ändern, um es auf lange Wege aufmerksam zu machen.
Warren P
3
@PatrickSzalapski leider wurde es behoben visualstudio.uservoice.com/forums/121579-visual-studio/…
phuclv

Antworten:

231

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.

valli
quelle
21
Die Windows-API begrenzt die Länge auch unter dem neuesten Betriebssystem. Microsoft hat Angst, Hunderte Millionen von heute verwendeten Betriebssystemen zu beschädigen, wenn sich dies ändern sollte, da keine Genies mehr für sie arbeiten, die die API in- und auswendig verstehen, wie dies in den 1980er und 1990er Jahren der Fall war. Das Risiko ist es nicht wert, es zu ändern. serverfault.com/questions/163419/…
MacGyver
77
@ MacGyver Sorry, aber das ist völliger Unsinn. Microsoft möchte nicht die Millionen schlecht geschriebener Anwendungen auflösen, die Dinge über das System annehmen , die niemals garantiert wurden. Leider waren die Dinge so lange so, dass Entwickler sich auf sie verlassen konnten. Wenn sie jetzt geändert werden, werden Anwendungen von Drittanbietern beschädigt, und MS wird dafür verantwortlich gemacht.
Basic
25
Übrigens gibt es keinen Beweis dafür, dass Gates jemals gesagt hat, der "640K Ram ist genug für alle" computerworld.com/article/2534312
Patrick Favre
11
@Basic Die Beschränkung auf 260 Zeichen wurde von Windows garantiert . Die Konstante wurde als Konstante deklariert, in den Windows-Header-Dateien wurde eine Struktur deklariert, die nur Platz für 260 Zeichen bietet. Es gibt keine Möglichkeit, dies zu ändern.
Ian Boyd
35
@Basic Die Konstante ändert sich nicht, sobald sie in meine Anwendung kompiliert wurde. Ich betreibe eine Anwendung , die letzte wurde gebaut im Jahr 1994 und läuft noch heute in Windows 10. Microsoft eine bestimmte binäre Größe eines Blocks von Speicher versprochen, und der Programmierer folgte dieser Regel. Wenn Microsoft die Konstante ändern würde, wäre jede vorhandene Anwendung, die die Programmier-API korrekt befolgt hat, fehlerhaft . Sie können die Binärkompatibilität nicht unterbrechen.
Ian Boyd
150

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.

Softveda
quelle
4
Fair genug, aber es bedeutet, dass Sie P / Invoke an vielen Stellen verwenden müssen, was meiner Meinung nach die Portabilität Ihres .Net-Codes verringert. Was ist, wenn ich die Monokompatibilität beibehalten möchte?
Jeffrey Cameron
1
Mein Punkt war, dass Sie einen langen Weg benutzen können, wenn Sie wirklich wollten. Aber ich stimme zu, dass es ein Schmerz ist und ich persönlich würde dies auch vermeiden.
Softveda
5
Dies sollte die gewählte Antwort sein. Beantwortet tatsächlich die vom Benutzer gestellte Frage, WARUM diese Grenze besteht UND bietet eine Problemumgehung. Upvote für Sichtbarkeit
KyleMit
2
Für mich klingt es so, als müsste Microsoft seine APIs reparieren, und ich denke, dies hat keine Priorität. Ich war überrascht, dass dieses Limit in Windows 8 noch besteht.
Mas
3
@Mas Das gewünschte "Update" wurde vollständig unter Windows XP durchgeführt. Durch Aufrufen der Unicode-Version ihrer API können Sie auf den "erweiterten Pfad" zugreifen. Ich glaube, der Explorer erledigt dies automatisch. Hier ist eine solche Funktion, die dies unterstützt - msdn.microsoft.com/en-us/library/windows/desktop/… .
Natalie Adams
108

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.

Ian Boyd
quelle
4
@JosiahKeller Wenn dies der Fall wäre, würde der ursprünglich für diese Methode definierte Vertrag gebrochen, 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-fähigen Varianten) und zu hoffen, dass jeder alle seine Anwendungen mithilfe der neueren API neu kompiliert / erneut veröffentlicht.
Rowland Shaw
2
@ Ryios Ich glaube nicht, dass meine vorhandenen Windows-Anwendungen unter Linux ausgeführt werden.
Ian Boyd
9
Abwärtskompatibilität ist nett. Ich denke jedoch, dass es heute wichtiger ist, solche (oft sehr schlimmen) Probleme zu vermeiden, als Windows 3.1-Anwendungen zu unterstützen. Wie viele Menschen haben Probleme mit zu langen Wegen? Und wie viele Benutzer verwenden noch Windows 3.1-Anwendungen? Sie haben sogar die Unterstützung für Windows XP eingestellt. Warum machen sie nicht einfach eine Ankündigung, dass von Windows [x] und späteren Anwendungen, bei denen davon ausgegangen wird, dass es keinen Pfad mit mehr als 260 Zeichen gibt, nicht wie erwartet funktioniert, wenn sie auf einen zu langen Pfad stoßen? Unsere Geschwindigkeitsbegrenzungen berücksichtigen auch keine Wagen.
JuSchu
2
@ JuSchu Es sind nicht nur Windows 3.1-Anwendungen. Anwendungen, die heute mit der richtigen API geschrieben wurden, funktionieren nicht.
Ian Boyd
62

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>
Wurzelschleife
quelle
15
Leider hat der Datei-Explorer selbst in der neuesten Version von Win10 immer noch Probleme mit dem Namen langer Pfade. Selbst "Als Pfad kopieren" im Kontextmenü funktioniert nicht wie erwartet. Es werden nur die ersten 260 Zeichen kopiert. Sie können keinen Ordner erstellen, keine Datei kopieren / verschieben / öffnen ... Lassen Sie mich fragen, wozu diese Änderung gut ist.
Raymai97
Beachten Sie, dass die Behauptung, dass die Systemeinstellung unabhängig von der Manifesteinstellung ist, falsch ist. Beides ist erforderlich. Die Richtlinie muss auf Systemebene aktiviert sein und das Manifest muss deklarieren, dass die Anwendung über lange Pfade informiert ist.
Eryk Sun
Ich habe gelesen, dass diese Änderung Kompatibilitätsprobleme mit älteren 32-Bit-Anwendungen verursachen kann. Ist diese Art von Kompatibilitätsproblemen jedoch häufig? Ich möchte die Änderung selbst vornehmen. lifehacker.com/…
KDP
32

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
Jonchang
quelle
Ich erhalte "Ungültiger Parameter j:", wenn
ich
Dies muss an einer Administrator-Eingabeaufforderung (erhöht) ausgeführt werden.
Mrchief
Dies schlägt bei Schrägstrichen fehl und muss ein Schrägstrich sein.
Cchamberlain
1
Ich bin nicht sicher, ob dies nur für Windows 10 gilt. Ich habe jedoch gerade festgestellt, dass beim Ausführen dieses Befehls das Laufwerk nicht verfügbar zu sein scheint, wenn ich wie oben vorgeschlagen als Administrator ausgeführt werde. Dies liegt daran, dass das Verhalten dem Zuordnen eines Netzwerklaufwerks zu ähneln scheint und sitzungsspezifisch ist. Wenn ich also als Administrator ausgeführt und diesen Befehl verwendet habe, kann diese Sitzung x: TL; DR verwenden. Wenn Sie das Laufwerk nicht sehen können, versuchen Sie es Ausführen des Befehls ohne Administratormodus.
Jaddie
substist local-session / account - siehe superuser.com/questions/29072/…, wie man es "systemweit" macht
user2864740
18

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
JDiMatteo
quelle
3
Musste das Verzeichnis nicht zuerst erstellen, daher ist Schritt 1 nicht erforderlich.
Ohaal
2
Dieser Trick funktioniert nicht immer, da viele Anwendungen versuchen, die Links aufzulösen
nponeccop
Die /jOption erstellt einen Junction-Mountpoint für ein lokales Volume-Gerät oder einen Pfad auf einem lokalen Volume (wie ein Unix-Bind-Mount). Es wird keine symbolische Verknüpfung erstellt. Dies ist eine wichtige Unterscheidung, da Junction-Mountpunkte immer auf einem Server ausgewertet werden und auf lokale Geräte abzielen müssen, während symbolische Links auf dem Client ausgewertet werden und auf Remotepfade abzielen können (sofern dies nach Richtlinien zulässig ist). Wie ein subst.exe-Laufwerk (dh DefineDosDeviceW) ist ein Junction-Ziel normalerweise auf etwa 4 KB Zeichen beschränkt. Es sind tatsächlich 8K-Zeichen, die ungefähr gleichmäßig zwischen dem Ersatzpfad und dem Anzeigepfad aufgeteilt sind.
Eryk Sun
12

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:

Gruppenrichtlinien-Editor

MovGP0
quelle
2
Jede Anwendung muss weiterhin erklären, dass sie über lange Wege informiert ist. Microsoft hat schlechte Arbeit geleistet, indem es den Eindruck erweckte, dass das Anwendungsmanifest nur eine andere Möglichkeit ist, diese Funktion zu aktivieren, anstatt klar zu erklären, dass es sich um einen Vertrag zwischen dem Betriebssystem (Richtlinie auf Systemebene) und der Anwendung handelt, in dem sich beide einig sein müssen.
Eryk Sun
8

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.

Conrad
quelle
1
Kurze Pfadnamen können in der Registrierung deaktiviert werden (oder war es das Dateisystem selbst?), Daher ist dies keine verlässliche Problemumgehung.
Rubenvb
3
@rubenvb Ich bin sicher, dass die meisten, wenn nicht alle Windows-Funktionen in der Registrierung deaktiviert werden können, also ¯ \ _ (ツ) _ / ¯
Conrad
Das Generieren von Kurznamen kann für NTFS deaktiviert werden (und sollte in vielen Fällen ineffizient sein), entweder für das gesamte System oder pro Volume. Daher ist dies ein unzuverlässiger Ansatz, selbst für Pfade auf dem Systemlaufwerk, bei denen es sich um NTFS handeln muss. Es ist möglich, Kurznamen für Dateien und Verzeichnisse in NTFS manuell festzulegen. Dies gilt jedoch nicht für neuere Dateisysteme, die überhaupt keine Kurznamen unterstützen, wie z. B. exFAT und ReFS. Kurznamen sollten als veraltete Funktion betrachtet werden, die aus Gründen der Kompatibilität in begrenzten Fällen beibehalten wird, wie beispielsweise die alte ANSI / OEM-API, die Einzel- und Doppelbyte-Codepages verwendet.
Eryk Sun
@eryksun Bitte lesen Sie meinen vorherigen Kommentar zum Deaktivieren von Kurzpfadnamen. :) Nur weil du denkst, dass es als veraltet angesehen werden sollte, heißt das nicht, dass es tatsächlich so ist. MS hat nicht vor, diese Funktion zu verwerfen. (Warum installieren Sie Windows-Software auf exFAT / ReFS-Partitionen?)
Conrad
Ich sage immer noch, nur nicht normalisierte Gerätepfade zu verwenden (dh "\\? \" Präfix), da sie immer verfügbar und offensichtlich sind. Übersetzen Sie es beispielsweise PATHund geben Sie es an weiter SearchPathW. Es ist auch effizient, da die Laufzeitbibliothek ohnehin "\\? \" - Gerätepfade für NT erstellt. Bei neueren Dateisystemen würde wahrscheinlich keine andere Software auf einem exFAT-Volume als bei tragbaren Anwendungen installiert sein, da diese keine Sicherheit bietet, aber ich würde ReFS nicht ausschließen. Benutzer installieren Programme aus Gründen der Benutzerfreundlichkeit, des Speicherplatzes oder der Leistung an nicht standardmäßigen Standorten.
Eryk Sun
7

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 .

Priidu Neemre
quelle
3
Ich habe mich geirrt, 7zip und WinRAR extrahieren alle Ordner und Dateien. Es ist nur so, dass die Eigenschaft eines Ordners in Windows nur die Anzahl der Ordner und Dateien angibt, die nicht gegen die Einschränkung verstoßen. Es ist, als würde der Windows Explorer nicht tiefer graben, um Ordner zu erkennen, wenn der maximale Pfad erreicht ist.
Twisted Whisper
Es ist möglich, einen langen Pfad in 7-zip mit shift-del zu löschen .
Laurie Stearn
Kurze Antwort - Verwenden Sie 7zip, um eine .zip-Datei zu entpacken .... funktionierte für mich unter Windows 7
andrewcockerham
2

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).

eliblanco87
quelle