Benötigen Sie symbolische Link-Funktionalität OHNE symbolischen Pfadnamen

472
Stephen Hanson

Windows 10 Pro ausführen.

Ich versuche, die 260-Zeichen-MAX_PATH-Einschränkung zu umgehen, die in der Win32-API enthalten ist.

Ich habe eine Reihe von Sicherungen erstellt, von denen wir sagen wollen, dass sie "TRUNCATED" -Dateinamen sichern.

Beispielsweise referenzieren wir eine Datei mit dem vollständigen Dateinamen:

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/Folder9/file.txt

Um zu beginnen, habe ich diesen Dateinamen theoretisch verkürzt, indem ich die Datei in einen versteckten Ordner in der Short_NameNähe der Wurzel verschoben habe, so dass die Datei jetzt LITERALL existieren würde

D:/Short_Name/Folder9/file.txt

Um jedoch meine ursprüngliche Dateistruktur intakt zu halten, kann ich diese Taktik erneut verwenden, um dieselbe Pfadkürzung an anderer Stelle auszuführen, aber immer noch dieselben Konfigurationsdateien und -software zum Duplizieren und Synchronisieren von Dateien innerhalb des ursprünglichen Ordners (s )

(wie D:/Folder1/.../Folder9/)

Ich habe einen symbolischen Link namens " Folder9" eingefügt.

(erreicht mit C:\Windows\system32> mklink /J(oder /D) "D:/Folder1/.../Folder9/" "D:/Short_Name/Folder9/"in der Eingabeaufforderung)

innerhalb

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/

so dass der Link aussieht

D:/Folder1/.../Folder9/

aber zeigt auf D:/Short_Name/Folder9/.

JETZT hätte ich natürlich stattdessen eine normale normale Maschine verwenden können

Rechtsklick> "Verknüpfung erstellen"

Der Link-Zielpfadname eines solchen symbolischen Links wäre jedoch absolut.

(dh Eine Verknüpfung beim D:Zeigen auf D:/Short_Name/Folder9/file.txtwürde kopiert werden, C:aber die kopierte Verknüpfung, auf die kopiert wird, C:würde immer noch auf zeigen D:/Short_Name/Folder9/file.txt.)

Symbolische Links dagegen ...

(dh diejenigen, die über erstellt wurden C:\Windows\system32> mklink ...)

... relative Links über kein Problem kopieren ...

(dh D:/Folder1/.../Folder9/würde kopiert werden als C:/Folder1/.../Folder9/)

... und das Linkziel würde von kopieren

D:/Short_Name/Folder9/

zu

C:/Short_Name/Folder9/

... ABER -

Das Problem HIER ist, dass JETZT die LITERAL-Dateinamen STILL INTERPRETIERT werden, da ihre längeren, UN-TRUNCATED-Versionen NICHT mit der

Rechtsklick> "Verknüpfung erstellen"

Methode.

Soweit ich feststellen kann, wenn Sie mklinkeinen symbolischen Link zu einem Verzeichnis erstellen (NICHT eine Datei - ich weiß nicht, ob es für Dateien anders funktioniert), erscheint der LITERAL-Systemdateiname einer Datei, die sich in einem Verzeichnis befindet, wie D:/Short_Name/Folder9/es nur scheint die Gesamtheit des mklinksymbolischen Pfads sein, dh der von

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/Folder9/file.txt

auch wenn der tatsächliche Speicherort der Datei nur ist

D:/Short_Name/Folder9/file.txt.

FRAGE:

Gibt es KEINE Möglichkeit, einen symbolischen Link zu erstellen, der als Standardordner fungiert, der aber auch die RELATIVE, LITERAL, TRUNCATED-Version eines Dateinamens beibehält, wenn er auf ein neues Laufwerk kopiert wird?

Bitte und Danke.

0
Ich verstehe nicht wirklich, was dein Problem ist. Möglicherweise möchten Sie jedoch [Namensdateien, -pfade und -namespaces] (https://msdn.microsoft.com/de-de/library/windows/desktop/aa365247 (v = vs.85) .aspx) lesen, die Besonderheiten aufweisen wie man mit längeren Pfaden arbeitet. Die naheliegendste und einfachste Lösung wäre außerdem, die Pfade zu verkürzen oder eine Software zu verwenden, die mit diesen Pfaden arbeiten kann. Ein Beispiel wäre, den Explorer nicht zu verwenden, sondern etwas wie Total Commander. Außerdem besteht ein großer Unterschied zwischen der Verwendung von "mklink" mit den Optionen "/ J" und "/ D". Seth vor 7 Jahren 0
Das Limit von MAX_PATH 260 ist ** nicht ** bezogen auf NTFS. Es ist nur das Limit der alten Win32-API. Windows NT unterstützt 32767-Zeichen für sehr lange Zeit und [Windows 10 unterstützt auch längere Pfade] (http://stackoverflow.com/a/27694470/995714) phuclv vor 7 Jahren 1
@Seth, der Unterschied besteht darin, 1.000 Dateinamen einzeln zu verkürzen und nur das längere Verzeichnis über einen symbolischen Link zu verkürzen. Ja, / J und / D sind unterschiedlich, aber die ISSUE, die ich habe, bleibt gleich, unabhängig davon, ob es sich um eine Kreuzung oder eine Soft-Link handelt. Ich kenne alternative Datei-Explorer. Ich möchte jedoch NATIVE Win32-API-Unterstützung, da dies die Umgebung ist, in der die meisten Entwickler von Drittanbietern ihre Anwendungen entwickeln. Umstellungsmethoden ** Die Verwendung von ** zum Durchsuchen von Dateien garantiert nicht, dass die über 1.000 Dateien, die ich habe, für ihre jeweiligen Anwendungen geeignet sind. Stephen Hanson vor 7 Jahren 0
@ LưuVĩnhPhúc Vielen Dank, dass Sie mich in Bezug auf Win32 korrigiert haben. Ich habe den ursprünglichen Beitrag entsprechend aktualisiert. Stephen Hanson vor 7 Jahren 0
@ LưuVĩnhPhúc Im Hinblick auf die Kompatibilität von Windows 10, da es sich auf längere Dateinamen bezieht, bin ich mir sicher, dass ich die Einstellung deaktivieren könnte, die derzeit Dateinamen mit mehr als 260 Zeichen nicht zulässt. Ich befürchte jedoch, dass dies zu Instabilität der Anwendung führen könnte. Gibt es eine Möglichkeit, auf die eine oder andere Weise zu bestätigen, wie das Ändern der Einstellung von MAX_PATH die Fähigkeit bestimmter Anwendungen beeinflussen könnte, die betroffenen Dateien zu verwenden? Stephen Hanson vor 7 Jahren 0
Es gibt keinerlei Probleme, da nur Anwendungen, die zur Unterstützung des langen Dateinamens vorgesehen sind, längere MAX_PATH-Werte haben, andere jedoch noch auf 260 Zeichen begrenzt sind, wenn sie keinen NT-Pfad verwenden. https://blogs.msdn.microsoft.com/jeremykuhne/ 2016/07/30 / net-4-6-2-and-long-path-on-windows-10 / https://news.slashdot.org/story/16/05/31/0012222/microsoft-removes- 260-Zeichen-Pfadlängen-Limit-in-Windows-10-Redstone phuclv vor 7 Jahren 0
@ LưuVĩnhPhúc, es sollte angemerkt werden, dass einige Zweifel darüber aufkommen, ob Windows * tatsächlich * das Anwendungsmanifest prüft, trotz der Angaben in der Dokumentation. Ich habe nicht versucht, das selbst zu bestätigen. Harry Johnston vor 7 Jahren 0
Aber wenn Sie Ihre Pfade tatsächlich korrigieren, müssen Sie wahrscheinlich nicht die Namen von tausend Dateien kürzen. Im Wesentlichen, was ich verstehe, ist das eh dein Ansatz. Es ist einfach nicht klar, wo Sie auf ein Problem stoßen. Wie aus dem ursprünglichen Link hervorgeht, können Sie einfach einen anderen Pfad verwenden und ihm einen Schuss geben. Normalerweise, wenn Sie ungewöhnliche Dinge ausführen, wie zum Beispiel das Überschreiten der Pfadlänge, benötigen Sie Werkzeuge, die Ihren Fall unterstützen oder Ihr Material korrigieren, damit es dem Standard entspricht. Seth vor 7 Jahren 0
@Seth Die Lösung, die ich suche, besteht darin, dass die Verzeichnisstruktur identisch mit einer Struktur mit vielen verschachtelten Verzeichnissen erscheint, z. B. einer, die Dateien mit Pfadnamen mit mehr als 260 Zeichen erstellt, sofern entweder ein Benutzer die Ordner im Explorer durchsucht oder wenn Eine Anwendung versucht, jede Verknüpfung / jedes Symlink / eine dritte potenzielle Alternative als einen tatsächlichen Ordner zu behandeln, wobei die ACTUAL-Pfadnamen jedoch kleiner sind. Abkürzung = yes, aber mit absoluten Pfadnamen, die nicht kopiert werden, Symlink (mklink) = relative Pfadnamen, die kopiert werden, jedoch keine kürzeren Pfadnamen. Stephen Hanson vor 7 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme