bestand-X heeft twee hardlinks

Bij bepaalde disk formaten zoals POSIX kan een document via meerdere wegen bereikt worden. Ongeacht welke pad je volgt naar het bestand, het zijn altijd dezelfde gegevens die gewijzigd worden. Normaal kan je niet zomaar een tweede link aanleggen naar een bestand (als je een 'opslaan als' uitvoert, dan wordt er een kopie van het bestand opgeslagen). Maar bepaalde operating systems ondersteunen de mogelijkheid wel. Bij het bestand zelf wordt aangegeven hoeveel links er naar het bestand wijzen (dergelijke filesystems moeten meta-data ondersteunen).

Multipele hardlinks worden weinig toegepast in de windows wereld omdat er weinig ondersteuning is (aanmaken en verbreken van links). Een hardlink kan enkel verwijzen naar een document op dezelfde partitie.

Hardlinks werken volledig transparant voor de uiteindelijke applikatie: in alle gevallen wordt er naar eenzelfde bestand verwezen en er is geen manier om te achterhalen welke link de originele is. Bij het wissen van een bestand dat meerdere links heeft wordt enkel de vermelding in de betreffende directory gewist. Enkel als de laatste link gewist wordt, wordt de ruimte die door het bestand gebruikt werd vrijgegeven.

Defragmentatieprogramma's zijn soms niet compatibel met hard links. Bij defragmentatie worden de verschillende delen van een bestanden samengevoegd (indien het bestand groter geworden is en de stukken niet meer aangrenzend zijn) en wordt de lokatie van het bestand soms gewijzigd. Het defragmentatieprogramma wijzigt slechts één referentie naar het bestand. De andere referenties wijzen nu naar plaatsen op de schijf die niet meer gebruikt zijn door het bestand.

Een snelkoppeling link verwijst naar een ander bestand

In het lnk-bestand kunnen er verschillende opties ingesteld worden (overgewaaid uit de PIF (Program Information File)), maar deze worden nauwelijks gebruikt.

Een snelkoppeling wordt door de shell (windows explorer) gebruikt om het effektief bestand op te sporen. Buiten de explorer shell (bijvoorbeeld in een command shell of een applikatie) werkt de snelkoppeling niet meer: het programma krijgt het lnk-bestand, niet het effektief bestand.

De snelkoppeling, het bestand link.lnk bevat niet het fysisch adres van het doelbestand, maar zijn volledig pad (/programs/adobe/photoshop/photoshop.exe). Hoewel het tekst en geen binaire data bevat kan het niet gewijzigd worden met een teksteditor: het bevat ook hexadecimale data.

/documents and settings/marc/documents/ bevat een softlink naar het bestand: de directory bevat het pad naar het bestand, niet zijn fysische lokatie

In plaats van het adres van het bestand (fysische adressering, zwarte pijl) bevat de directory de echte path naar het bestand (groene pijl). Als het bestand opgevraagd wordt, wordt de link volledig transparant gevolgd door het operating system. Het programma ziet niet dat er "redirection" gebeurt is. Zoals bij een hardlink wordt er naar eenzelfde bestand verwezen.

Symbolic links zijn plots opgedoken in Vista, toen microsoft zijn bestandsstruktuur volledig door elkaar heeft gehaald. Symbolic links werken ongeveer (een hele prestatie voor microsoft), maar bieden niet alle functionaliteiten van symbolische links onder unix. Eigenlijk zijn deze softlinks erbij gehaald omdat microsoft dezelfde functionaliteiten aan de gebruikers wou bieden: terwijl vroeger de documenten opgeslagen werden in /documents and settings/<gebruiker>/documents zitten ze nu in /users/<gebruiker>/documents. Vaak zijn de programma's niet aangepast aan deze nieuwe manier van doen en gaan ze de documenten opslaan op een onbestaande plaats.

Om dit op te lossen zijn er een hoop symbolische links aangemaakt door het operating system. Deze gebruiken de oude namen en verwijzen naar de nieuwe lokaties van de bestanden. Programma's kunnen de bestanden via de oude lokatie (symbolic link) of de effektieve lokatie raadplegen: het resultaat is hetzelfde. De symbolic link is een verwijzing naar het pad van het bestand, niet naar de lokatie ervan.

In dit voorbeeld (ik heb de schijf op een unix systeem gemonteerd, want windows toont geen symbolische links) heb je de symbolische link c:\Documents and Settings\User\Mijn documenten (ik gebruik hier even de windows benaming) die verwijst naar c:\Users\User\Documents\ (de echte lokatie waar de documenten zitten). Unix toont een "snelkoppeling" tekentje in de directory (en niet bij een bestand zoals bij een echte snelkoppeling). Windows toont gewoon niets, complete ondersteuning voor symlinks is er niet onder vista en windows 7. Je ziet dus niet of je te maken hebt met een koppeling of met het echte bestand.

Sinds microsoft de symbolische links ontdekt heeft zijn ze wild van symlinks. Als je niet oplet en je copieert de inhoud van een usb stick naar je computer is de kans groot dat microsoft er een symlink van gemaakt heeft in plaats van de bestanden echt te copiëren (bij windows duurt het aanmaken van een symlink blijkbaar even lang als het overzetten van 2GB aan data). Omdat microshit niet aangeeft dat je te maken hebt met een koppeling en niet met de echte bestanden merkt je de vergissing pas dagen later, als je de bestanden wilt lezen. Oeps! En de usb stick is al lang opnieuw geformateerd...

Symbolische links en snelkoppelingen kunnen verwijzen naar onbestaande doelen (bijvoorbeeld als het effektief bestand gewist wordt), omdat er geen manier is om deze links op te sporen. Er wordt ook niet bijgehouden hoeveel inkomende links een bestand heeft. Opkuisprogramma's kunnen dode snelkoppelingen opsporen en verwijderen, maar er zijn weinig opkuisprogramma's die eveneens de symbolische links kunnen opruimen (deze zijn te recent opgedoken in de windows wereld).

De hier voorgestelde struktuur van een filesysteem (een “volume” om de juiste benaming te gebruiken) is zeer algemeen en niet specifiek gebonden aan een operating system of formaat. In het algemeen zal het filesysteem nog extra informatie moeten bevatten, een FAT (file allocation table) of een linked list om snel vrije ruimte te kunnen localiseren en toewijzen als er een nieuw bestand aangemaakt wordt.