Windows-junctie: de map die eigenlijk ergens anders staat

Stel je voor dat de deur van je bijkeuken niet uitkomt in een bijkeuken, maar via een geheime doorgang recht in de garage van de buren. Iedereen die de deur opent, merkt niets vreemds: je loopt naar binnen, ziet dozen en gereedschap staan, en pakt wat je nodig hebt. Dat de ruimte in werkelijkheid ergens anders ligt, doet er voor de gebruiker niet toe. Zoiets is een Windows-junctie: een map die er op je scherm uitziet als een gewone map, maar die in werkelijkheid alleen doorverwijst naar een andere map, ergens anders op je schijf.

Deze techniek is geen nieuwe uitvinding en al helemaal geen kunstmatige intelligentie of futuristische innovatie: het is een bestaand, stil onderdeel van het Windows-bestandssysteem dat al ruim twintig jaar meedraait. Toch duikt de term regelmatig op, bijvoorbeeld bij software-installaties, back-uptools of programmeeromgevingen, en zorgt hij dan voor verwarring. Wie begrijpt wat een junctie is, snapt meteen waarom sommige mappen zich vreemd gedragen: waarom verwijderen soms gevaarlijk is, waarom een schijf ineens "vol" lijkt terwijl dat niet zo is, of waarom een installatieprogramma bestanden op een heel andere schijf blijkt te zetten dan je dacht.

Wat is het precies?

Een Windows-junctie (in het Engels junction point of directory junction) is een speciaal type map in het bestandssysteem NTFS, het standaardsysteem waarmee Windows bestanden en mappen op een schijf bijhoudt. Een junctie bevat zelf geen bestanden. In plaats daarvan bevat hij één simpel gegeven: het pad naar een andere map. Elk programma dat de junctie opent — de Verkenner, een spelletje, een back-upprogramma — krijgt automatisch de inhoud van die andere map te zien, zonder dat het programma zelf hoeft te weten dat er iets bijzonders aan de hand is.

Technisch gezien werkt dit via een mechanisme dat reparse point heet. Dat is een klein label dat Windows aan een map hangt, met de instructie: "stop hier niet, maar ga verder bij dit andere adres". Dit gebeurt op het niveau van het bestandssysteem zelf, dieper dan waar de meeste programma's ooit kijken. Dat is meteen het verschil met een gewone snelkoppeling, het bekende bestand met extensie .lnk. Een snelkoppeling is namelijk gewoon een klein bestandje dat alléén de Verkenner herkent en interpreteert als "klik hier om ergens anders heen te gaan". Een programma dat rechtstreeks in dat bestand kijkt, ziet alleen een paar regels tekst. Een junctie daarentegen wordt door élk programma automatisch gevolgd, omdat het bestandssysteem zelf de omleiding regelt.

Junctie is verwant aan, maar niet hetzelfde als, een symbolische koppeling (symbolic link of symlink), een ander soort reparse point dat Windows sinds Windows Vista (2007) ook kent. Beide verwijzen naar een ander pad, maar er zijn twee praktische verschillen. Ten eerste werken junctions alleen voor hele mappen en alleen naar plekken op dezelfde computer; ze kunnen niet naar een map op een andere computer in het netwerk wijzen. Symbolische koppelingen kunnen dat wel, en werken ook voor losse bestanden. Ten tweede vereisten symbolische koppelingen lange tijd speciale rechten (beheerdersrechten) om aan te maken, terwijl junctions dat nooit hebben gedaan — een detail dat, zoals verderop blijkt, best belangrijk is gebleken.

Aanmaken doe je met het commando mklink /J in de opdrachtprompt, of met New-Item -ItemType Junction in PowerShell. Wil je zien of een map eigenlijk een junctie is, dan toont dir /AL dat in een mapoverzicht, en fsutil reparsepoint query laat de technische details zien. Nauw verwant is het zogeheten volumekoppelpunt (volume mount point): daarmee koppel je een hele harde schijf of partitie aan een lege map, in plaats van er een stationsletter (zoals D: of E:) aan te geven. Dat gebruikt precies hetzelfde onderliggende mechanisme als een junctie, alleen wijst het naar een heel volume in plaats van naar een submap.

Wat wil men ermee bereiken?

Het doel van junctions is in de kern heel praktisch: de plek waar gegevens fysiek staan loskoppelen van de plek waar programma's ze verwachten. Veel oudere software gaat er hardnekkig van uit dat bepaalde bestanden op een vast pad staan, bijvoorbeeld in een map met een specifieke naam op de systeemschijf. Als je die gegevens om welke reden dan ook wilt verplaatsen — naar een snellere schijf, naar een schijf met meer ruimte, of naar een netwerklocatie die eruitziet als een lokale map — dan zou je zonder junctions elk programma dat ernaar verwijst apart moeten aanpassen. Met een junctie op de oude plek, die doorwijst naar de nieuwe locatie, hoeft dat niet: alle software blijft gewoon werken, zonder dat er ook maar één regel code hoeft te veranderen.

Een tweede, minstens zo belangrijke drijfveer is achterwaartse compatibiliteit tussen Windows-versies. Wanneer Microsoft de interne mappenstructuur van Windows verandert, kan een junctie de oude padnamen laten "overleven" voor software die daar nog naar zoekt, terwijl de werkelijke bestanden allang ergens anders staan.

Ten derde is er een heel ander motief bijgekomen dat weinig met Windows zelf te maken heeft: schijfruimte en snelheid besparen bij software-ontwikkeling. Ontwikkelaars werken vaak met tientallen projecten die dezelfde programmeerbibliotheken gebruiken. In plaats van elke bibliotheek voor elk project apart te kopiëren, wordt één centrale kopie bewaard en linkt elk project daar via een junctie of vergelijkbare koppeling naartoe. Dat scheelt zowel opslagruimte als installatietijd.

Voorbeelden uit de praktijk

Een bekend historisch voorbeeld is Windows Vista (2007), dat de gebruikersmappen verplaatste van het oude pad C:\Documents and Settings naar het nieuwe C:\Users. Om te voorkomen dat verouderde programma's die nog naar het oude pad verwezen zouden crashen, liet Microsoft de oude mapnaam gewoon bestaan als junctie die automatisch doorverwees naar de nieuwe locatie.

Vóór Windows Vista bestond er nog geen ingebouwde manier om zelf junctions te maken. In die periode ontwikkelde Mark Russinovich, destijds bekend van zijn onafhankelijke systeemtools onder de naam Sysinternals (later overgenomen door Microsoft), een los gereedschap dat simpelweg Junction heette. Daarmee konden systeembeheerders en gevorderde gebruikers al vóór de officiële ondersteuning met dit mechanisme experimenteren.

In de wereld van webontwikkeling gebruikt de populaire pakketbeheerder pnpm op Windows junctions (samen met zogeheten hard links) om pakketten uit een centrale, gedeelde opslagmap in de node_modules-map van een project te plaatsen. Dat is precies het schijfruimte-motief uit de vorige paragraaf in de praktijk: honderden projecten kunnen dezelfde bibliotheekbestanden delen zonder ze telkens te dupliceren, en dat kan zonder dat de gebruiker beheerdersrechten nodig heeft.

Ook systeembeheerders gebruiken junctions regelmatig om, bijvoorbeeld op servers, een map met loggegevens of databestanden te "verplaatsen" naar een aparte, grotere schijf, terwijl de software blijft denken dat alles nog op de oorspronkelijke systeemschijf staat.

Tot slot maken sommige tools voor virtualisatie en ontwikkelomgevingen, zoals installaties die Linux-achtige omgevingen op Windows nabootsen, gebruik van reparse points en junctions om bestanden tussen verschillende bestandssysteemwerelden zichtbaar te maken zonder ze fysiek te kopiëren.

Hoe ver is de techniek?

Hier wijkt dit onderwerp af van de meeste artikelen over toekomsttechnologie op deze site: een Windows-junctie is geen opkomende technologie die nog moet rijpen, maar een volwassen, stabiel onderdeel van Windows dat al sinds Windows 2000 bestaat, als onderdeel van bestandssysteemversie NTFS 5.0. Er is dus geen ontwikkeltempo of routekaart zoals bij bijvoorbeeld kwantumcomputers of kernfusie; het is bestaande, uitontwikkelde infrastructuur die nog steeds actief wordt gebruikt.

Wel is de ondersteuning eromheen in de loop der jaren gegroeid. Het commando mklink kwam er pas in Windows Vista bij; daarvoor moest je externe tools gebruiken. Later, met de introductie van de zogeheten "ontwikkelaarsmodus" in Windows 10 (rond 2016), werd het ook voor gewone gebruikers eenvoudiger om de nauw verwante symbolische koppelingen te maken zonder beheerdersrechten — een verandering die het onderscheid tussen junctions en symlinks voor sommige toepassingen minder scherp maakte, al blijven junctions op punten als netwerkcompatibiliteit anders werken.

Het belangrijkste "obstakel" is niet technisch van aard, maar zit in gebruikersfouten. Omdat een junctie er in de Verkenner bijna identiek uitziet aan een gewone map, is het risico reëel dat iemand een junctie per ongeluk behandelt alsof de inhoud er echt staat. Wie een junctie verwijdert met een opdracht die bedoeld is om een hele mapinhoud recursief te wissen, kan zo onbedoeld de bestanden in de dóelmap verwijderen, terwijl de bedoeling alleen was de verwijzing zelf weg te halen. De veilige manier is de junctie zelf te verwijderen zonder de inhoud aan te raken. Dit is precies waarom kennis over dit onderwerp nuttig blijft: het gaat niet om spectaculaire vooruitgang, maar om een onopvallend mechanisme dat, verkeerd begrepen, tot dataverlies kan leiden.

Wie werken eraan?

Microsoft is en blijft de enige partij die het NTFS-bestandssysteem en de bijbehorende reparse-point-technologie onderhoudt en doorontwikkelt, als onderdeel van Windows zelf. Het voormalige onafhankelijke bedrijf Sysinternals, opgericht door Mark Russinovich en Bryce Cogswell, speelde in de begindagen een belangrijke rol door hulpmiddelen te bouwen die de functionaliteit al toegankelijk maakten vóórdat Microsoft die officieel ondersteunde; Sysinternals is inmiddels onderdeel van Microsoft zelf.

Buiten Microsoft zijn het vooral makers van ontwikkelaarsgereedschap die de techniek actief toepassen: het team achter de pakketbeheerder pnpm is een voorbeeld van een project dat junctions bewust inzet als bouwsteen van zijn eigen systeem. Daarnaast bouwen onafhankelijke ontwikkelaars aanvullende gereedschappen, zoals grafische hulpprogramma's waarmee junctions makkelijker te maken en te herkennen zijn dan via de opdrachtregel. Dit is dus geen onderzoeksveld met laboratoria of overheidsprogramma's; het initiatief ligt bij één platformleverancier (Microsoft) en een reeks softwaremakers die op dat platform voortbouwen.

Verder lezen

• Microsoft Learn — officiële technische documentatie over NTFS, reparse points en de opdrachten mklink en fsutil.
• Sysinternals — de door Microsoft overgenomen verzameling systeemtools van Mark Russinovich, met achtergrond over hulpmiddelen als de oorspronkelijke Junction-tool.
• NTFS.com — onafhankelijke referentiesite met technische uitleg over het NTFS-bestandssysteem.
• pnpm — officiële site van de pakketbeheerder die junctions gebruikt voor efficiënte pakketopslag op Windows.
• Wikipedia — achtergrondartikelen over NTFS en bestandssysteemconcepten als reparse points en symbolische koppelingen.