nicht selten habe ich das Problem, dass mich die Einschränkung der Pfadtiefe auf 255 Zeichen in Windows erwischt (hier nur als eine exemplarische motivierende Ursache, es gibt sicher mehr Nutzen für das Ganze). Bisher habe ich einfach auf der Kommandozeile z.B.
subst X: C:\MyVeryDeep\Folder\Structure
benutzt. Das funktioniert zuverlässig.
Jetzt wollte ich im SQL Server mit OPENROWSET ( BULK ) Files per Skript importieren. Interessanterweise funktioniert das nur, wenn ich den absoluten Pfad zum File angeben kann. Verwende ich einen Pfad, der mit subst erzeugt wurde, funktioniert es nicht. Ich denke, es liegt daran, dass der SQL Server Dienst nichts vom subst des interaktiven Benutzers weiß.
Jetzt habe ich von NTFS Juntion Points gelesen. Das geht mit dem sysinternals Tool junction.exe leicht von der Hand und fühlt sich fast an wie ein subst:
Laut Doku bedeutet -s "Rekursion in Unterverzeichnissen". Ich habe das als "Verzeichnis inkl aller Unterverzeichnisse interpretiert". Wenn ich aber jetzt so drüber nachdenke, kann das viel heißen. Womöglich auch, dass rekursiv alle Unterverzeichnisse als JunctionPoints eingebunden werden?? Da ich ja jetzt gelernt habe, dass mklink auch Junctions kann, brauch ich das Tool samt seiner Option -s eh nicht mehr ;-)
Nee, Du hängst immer einen kompletten Ordner samt aller Unterordner ein. So wie ich das verstehe, ist das -s nur für den "Lesemodus" gedacht - d.h. wenn Du nur einen Ordner als Parameter angibst und dann alle junctions darin angezeigt bekommst bzw. testest, ob ein bestimmter Ordner eine junction ist.
Der Unterschied zwischen subst und NTFS junctions ist ganz grundsätzlicher Natur. Beide ermöglichen es, eine Art Alias oder Mapping für einen Ordner einzurichten. Während aber eine NTFS junction eine Funktion des Dateisystems NTFS ist und dieses Mapping direkt in der Struktur des Dateisystems verankert, ist subst eine Funktion des Betriebssystems und löst das Problem, in dem es Windows instruiert, das Mapping beim Zugriff auf das Dateisystem auszuführen.
Daraus und aus der konkreten Implementierung ergeben sich eine Reihe weiterer Unterschiede:
subst:
Als Quelle des Mappings können nur (neue) Laufwerkbuchstaben verwendet werden, keine tiefer liegenden Ordner wie bei junctions.
Damit können max. 25 Mappings gleichzeitig verwendet werden (Windows kann nur 26 Buchstaben vergeben, und mindestens einer ist immer schon weg.)
Funktioniert mit (fast?) allen Windows-Versionen, OS/2 und MS-DOS.
Das Mapping-Ziel kann ziemlich beliebig sein, insbesondere auch eine FAT32-Partition oder ein Netz-Laufwerk.
Ist per default erst mal nicht persistent. Es gibt mehrere mögliche Ansätze, ein subst-Mapping persistent zu machen. Der vielleicht einfachste ist eine Batch-Datei im Autostart-Ordner, einen komplizierteren und mächtigeren zeigt der Wikipedia-Artikel zu subst (soll angeblich auch für Services klappen, hab selbst keine Erfahrung damit; der Artikel scheint mir auch sonst recht lesenswert zu sein). Aber wie auch immer: die Persistierung ist auf die konkrete Betriebssystem-Instanz oder sogar das Nutzerprofil beschränkt. Mounte ich die Platte in einer anderen Windows-Instanz oder gar in einem anderen OS, ist das Mapping nicht aktiv.
junctions:
Quelle des Mappings sind Ordner. Neue Laufwerke können damit keine eingeführt werden.
Theoretisch können beliebig viele Mappings gleichzeitig aktiv sein.
Funktioniert prinzipiell mit allen Betriebssystemen, die NTFS können. Auch Linuxe können prinzipiell NTFS junctions lesen. Ist wohl aber nicht in allen NTFS-Zugriffsmodulen unter Linux aktiv bzw. implementiert.
Die Mapping-Quelle muss ein NTFS-Ordner sein, das Ziel ein lokaler Pfad - geht also nicht mit Zielen auf einem Netz-Laufwerk.
Ist immer persistent. Egal, wo ich die Partition mounte - wenn das jeweilige OS NTFS inkl. junctions unterstützt, ist das Mapping aktiv.
Soweit zu den Unterschieden. Beim Recherchieren hab ich noch zwei nützliche Links gefunden:
Dieser Microsoft-KB-Artikel gibt u.a. auch Empfehlungen zur Verwendung von junctions. Habe sie selbst nicht ausprobiert, aber sie scheinen mir sinnvoll. Nach meiner bescheidenen Erfahrung sind junctions nützlich, aber gefährlich wg. der unklaren bis nicht vorhandenen Unterstützung in einer Reihe von Programmen einschließlich des Windows-Explorers (zumindest bis XP). Es ist schwierig vorherzusagen, was passiert, wenn ein Programm den source-Ordner der junction löscht oder ihn sonstwie nutzt. Ich hab mir mal eine Windows-XP-Installation beschädigt, indem ich den Ordner, in dem die Windows-Updates abgelegt werden, aus Platzmangel auf eine andere Partition verschoben und per junction am alten Ort eingebunden habe. Blöderweise hatte wohl der Programmierer des Windows-Update-Clients noch nie was von junctions gehört, jedenfalls war nach dem nächsten Update der Ordner leergeputzt!
Neben junctions kann NTFS auch noch hard links für Dateien und symbolische Links für Dateien und Verzeichnisse. Dieser Blog-Post erklärt die Unterschiede und wie man die einzelnen Varianten mit mklink erzeugt.
Danke für diese sehr ausführliche und aufschlussreiche Antwort. Damit bin ich in Zukunft gut gerüstet, um zu entscheiden, welche Art von Link sich für einen konkreten Anwendungsfall empfiehlt. Ich werde aber wohl am Anfang etwas disziplinierter damit umgehen, als ich das bisher mit subst gemacht habe. Schön, dass ich die Fallstricke und Möglichkeiten jetzt kenne. Danke.
ich hab bisher von soften und harten Links die Finger gelassen, das war mir zu heiß. (.lnk nutze ich natürlich.) Ungefähr bewusst ist mir bloß, was dazu mal in der c't stand, und was ich auf wikipedia gefunden habe, das scheint mir aber ganz gut: https://de.wikipedia.org/wiki/Junction_Point, https://de.wikipedia.org/wiki/Harter_Link. Seit Vista kann Windows selbst junction points anlegen. Die verhalten sich dann aber wieder ein bisschen anders als die, die vom Russinovich-Tool angelegt werden (!?): http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx. Fazit für mich: Bevor ich davon nicht jedes Detail verstanden habe, lasse ich die Finger davon, <Edit>zumal sich jedes Tool von MS / Sysinternals zum Anlegen der verschiedenen Verknüpfungsarten zu jeder Windowsversion wieder anders verhält.</Edit> Und da ich zwischen verschiedensten Systemen springen und wie du mit dem MSSQL jonglieren muss, mag ich mich darauf nicht verlassen.
Zum Grundthema: Ich muss(te) öfter mal MSSQL-.baks auf Netzshares schreiben. Und UNC-Pfade sind kein Problem. Das hab ich auch schon für .baks auf den aktuellen Client genutzt: Lokale Freigabe erzeugt, und aus Umgebungsvariable %computername% und dem von mir definierten Freigabenamen einen lokalen Pfad zusammengesetzt. Warum solltest du nicht auch Freigaben fürs Pfadkürzen nutzen können? Vielleicht liegt es an meiner mangelnden Erfahrung mit junctions und anderen symb. Verknüpfungen, aber mir scheinen Freigaben besser steuer- und beherrschbar. Ein Problem ist möglicherweise, dass die Freigabendefinition Adminrechte verlangt.
Und dann gibt es ja noch die 8.3-Namen, die oft kürzer sind als die "Long File Names". Und die sind immer da, ohne definiert werden zu müssen, die musst du bloß ggf. ermitteln.
Leider kann ich dir den Unterschied zwischen subst und junction nicht wirklich erklären, das ist mir bewusst. Das Aufsatzthema hab ich jedenfalls verfehlt ;-)
+1 und besten Dank für Deine ausführliche Meinung zum Thema. Dass das Russinovich-Tool und Windows Bordmittel anders vorgehen, hätte ich nicht erwartet. Der Share ist eine gute Alternative. Merk ich mir.
Vielleicht findet sich ja noch jemand, der uns beiden den Unterschied bzw. die Möglichkeiten und Fallstricke von Junction Points erläutern kann. Irgendwie nützlich find ich das allemal, dafür hätt ich schon Verwendung (die schnell übers einfache Pfadkürzen hinausgeht).
@mupan: wie kommst Du darauf, dass sich die von Windows selbst angelegten junctions und die von junction.exe erzeugten junctions unterschiedlich verhalten? Ich sehe in dem von Dir verlinkten Artikel keinen Hinweis darauf. NTFS unterstützt verschiedene Arten von Verlinkungen (siehe Link am Ende meiner Antwort). Man kann sie seit Vista alle mit mklink erzeugen. Ich wüßte nicht, worin sich das Ergebnis von junction source target und mklink /J source target unterscheiden sollten. Hast Du dazu Quellen?
Hi Matthias, danke für's Nachfragen, es sind natürlich die Tools, die sich unterschiedlich verhalten. Ändert nichts an meiner Grundaussage, aber korrekt wollen wir schon alle sein.
statt junction.exe gibts ab Vista auch die Möglichkeit Links/Junctions per mklink.exe auf der Kommando-zeile zu erzeugen (/J ist die Junction). Dieses Tool ist "mächtiger", es bietet mehrere Möglichkeiten. Nachteile sind mir keine bekannt, es erfordert halt nur Disziplin z.B. beim Löschen (damit man sich nachher nicht wundert warum dieses und jenes auch gelöscht wurde). Vermieden werden sollten Links auf Links (auch indirekt), da so Schleifen entstehen können und diese könnten Probleme bereiten.
Junctions werden z.B. ab Vista auch verwendet um die länderspezfischen Ordner zu erstellen. Beispiel: "richtiger" Ordner ist c:\Users, auf deutschem OS wird aber c:\Benutzer angezeigt. Das wurde über eine solche Junction gelöst.
subst ertellt eine virtuelles Laufwerk (nicht zu verwechseln mit virtueller Festplatte) und läuft im Kontext des aktuellen Benutzers - daher kann der Dienst das nicht sehen. Auch wenn du es als Admin ausführst, so gilt das nur für den Admin-Account. Mit mklink (od. junction) werden symbolische/harte Verknüpfungen erstellt, die (einfach ausgedrückt) direkt in NTFS gespeichert, daher kann auch der Dienst dies erkennen.
net use wäre noch eine Möglichkeit, aber mklink ist für mich die einfachste und beste.
+1. Danke für Deine Hinweise. Das hat schon mal viel Licht ins Dunkel gebracht. Das grüne Häkchen geb ich Matthias für seine sehr ausführliche Antwort.
Wenn ich aber jetzt so drüber nachdenke, kann das viel heißen. Womöglich auch, dass rekursiv alle Unterverzeichnisse als JunctionPoints eingebunden werden??
Da ich ja jetzt gelernt habe, dass mklink auch Junctions kann, brauch ich das Tool samt seiner Option -s eh nicht mehr ;-)