Erstellen Sie in Windows 10 einen relativen symbolischen Link für Dateikopien

Sie verwenden falsche Schrägstriche, wenn Sie aus dem aktuellen Verzeichnis auf ein übergeordnetes Element verweisen möchten. In diesem Fall müssen Sie einen Backslash verwenden. Vorwärtsschrägstriche funktionieren, wenn Sie nur auf Kinder verweisen möchten. Bei einem absoluten Pfad scheint es keine Rolle zu spielen.

mkdir C:\temp\example\a mkdir C:\temp\example\b\c mklink /D C:\temp\example\a\redirection ..\b 

Verwenden Sie für die Begrenzung von 260 Zeichen eine Anwendung, die es behandelt, anstatt nach einer leicht zu brechenden Problemumgehung zu suchen oder Ihre Pfade zu verkürzen.

Drei Dinge:

1. Verwenden Sie keine symbolischen Links, es sei denn, dies ist unbedingt erforderlich, da Sie standardmäßig als Administrator angemeldet sein müssen. Wenn Sie nur Verzeichnisse lokal verknüpfen möchten, verwenden Sie Junctions, die auch von einem eingeschränkten Standardbenutzer unterstützt werden.

2. Versuchen Sie, Software zu ersetzen, die keine langen Unicode-Dateinamen unterstützt, was häufig möglich ist. Diese langen Dateinamen gibt es schon seit NTFS und Windows NT, daher sollte Software dies einfach unterstützen, und viele Frameworks / Runtimes wie Java tun dies standardmäßig. Software, die Dinge kopieren oder sichern soll, die keine langen Dateinamen unterstützt, ist ziemlich fehlerhaft und hat sicherlich auch andere gravierende Einschränkungen, insbesondere bei Backups. Denken Sie an Dinge wie Berechtigungen, den richtigen Umgang mit verschiedenen Links und Dateitypen, alternative Datenströme usw. Man muss vorsichtig sein.

3. Der Grund für Ihr tatsächliches Problem scheint in den Unterschieden in den symbolischen Links und in den Junctions zu liegen oder möglicherweise in der Art und Weise, wie die von der Shell bereitgestellten Pfade analysiert werden:

C: \ Users \ tschoening \ Documents \ test \ target> mklink / J "[target]" "../ src / {[murks]}"

Verbindung erstellt für [target] << === >> ../ src / {[murks]}

C: \ Users \ tschoening \ Documents \ test \ target> cd "[target]"

C: \ Benutzer \ tschoening \ Documents \ test \ target [target]> cd ..

C: \ Benutzer \ tschoening \ Documents \ test \ target>

Wie Sie sehen können, funktioniert der Zugriff auf "[Ziel]" auf diese Weise, während Folgendes nicht den gleichen Fehler erzeugt wie Sie, und zwar nur auf Deutsch:

C: \ Users \ tschoening \ Documents \ test \ target> mklink / D "[target]" "../ src / {[murks]}"

symbolische Verknüpfung erstellt für [target] << === >> ../ src / {[murks]}

C: \ Users \ tschoening \ Documents \ test \ target> cd "[target]"

Die Syntax für den Dateinamen, die Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.

C: \ Benutzer \ tschoening \ Documents \ test \ target>

Zumindest sehe ich in meinem Test keinen anderen Unterschied als / J vs. / D, aber mir fehlt natürlich etwas. Ich empfehle daher, den Test mit Junctions selbst zu wiederholen.

Einige weitere interessante Dinge, die ich gerade erkannt habe: Das Öffnen des erstellten Symlinks mit der obigen Syntax in cmd.exe und Windows Explorer schlägt fehl, aber es gelingt in Link Shell Extension. Schauen Sie sich den folgenden Screenshot an, der den relativen Pfad zeigt. Durch Klicken auf "Ziel öffnen" wird ein neuer Windows Explorer-Ordner mit dem Linkziel geöffnet. Sieht so aus, als ob die Link Shell Extension / sich selbst interpretiert und \ der zugrunde liegenden Windows-API zur Verfügung stellt. Etwas, das Windows selbst nicht tut, sondern einfach die Verwendung von / as im Link selbst, was für Pfade falsch ist. Wie @Seth bereits erkannt hat, ist das / selbst das Problem mit den Symlinks.

Zunächst sollten wir uns die Syntax der Optionen und erforderlichen Parameter ansehen, die durch Eingabe der Hilfeanforderung für den mklinkBefehl generiert werden mklink /?:

MKLINK [[/D] | [/H] | [/J]] Link Target  /D Creates a directory symbolic link. Default is a file symbolic link. /H Creates a hard link instead of a symbolic link. /J Creates a Directory Junction. Link Specifies the new symbolic link name. Target Specifies the path (relative or absolute) that the new link refers to. 

Derzeit ist es nur möglich, relative Dateipfad-Daten in Verzeichnissymbolverknüpfungen einzuführen.

Deshalb müssen wir die Verwendung mklinkBefehl in Verbindung mit der ( „Soft - Link“) mklinkBefehlsoption, /Dwie so.

mklink /D. . .

Der mklink TargetParameter muss einen Dateipfad beschreiben, der mindestens einen RELATIVE FILEPATH-OPERATOR enthält, z. B. .oder ..in Verbindung mit so vielen BACKSLASHES ( \), wie es die relative Hierarchie von (Grand-, Great-Grand- usw.) übergeordneten Verzeichnissen sowie dies erfordert einen "DOUBLE-QUOTED- "Dateipfad in jedem Fall, in dem ein oder mehrere Whitespace-Zeichen für ein untergeordnetes ABSOLUTE-Dateipfadfragment des zu verkettenden relativen mklink TargetDateipfad der Verknüpfung erforderlich sind.

Der Befehl wurde beendet

mklink /D "C:/Test Folder/Link Name With Spaces". . .

indem Sie den mklink TargetParameter mit ersetzen

. . ...\"Target Name With Spaces"

oder

. . ."..\Target Name With Spaces"

erstellt ein erfolgreich verkettetes relatives Dateipfadziel innerhalb einer Verknüpfung, die am erstellt wird

C:/test foldEr/Link Name With Spaces

und Fertigstellung

mklink /D "C:/Test Folder/Test Folder 2/Link Name With Spaces". . .

mit

. . ."..\..\Target Name With Spaces"

oder

. . ...\..\"Target Name With Spaces"

wird einen Link bei erstellen

C:/Test Folder/Test Folder 2/Link Name With Spaces.

In allen vier Fällen ist das Endergebnis ein Verzeichnissymbollink, der auf das Verzeichnis verweist

C:/TaRget nAme WitH SpacEs.

der jedoch auf einen anderen Speicherort verweist, wenn eine der generierten Verknüpfungen in einen anderen Ordner verschoben wird, entweder durch einen Befehl wie robocopyoder durch eine Anwendung, die symbolische Verknüpfungen in ähnlicher Weise berücksichtigt.