En symbolsk lenke (på engelsk soft link , symbolic link eller symlink ved avkorting) er en spesiell katalogoppføring i moderne Unix eller Unix-lignende systemer som gjør det mulig å referere til andre katalogoppføringer nesten gjennomsiktig, vanligvis vanlige filer eller kataloger, inkludert på forskjellige lagringsvolumer (som en vanlig lenke ikke tillot). Det oppfører seg som et alias for en vanlig fil eller katalog.
Vi kaller dereferanse til operativsystemet for å erstatte navnet på den symbolske lenken med det den peker på.
Den systemkall som gjør det mulig å finne filen peker til lenken er readlink .
Under et Unix-system, blir symbolske lenker skapt av tilstedeværelsen av -sden kommandoen alternativ ln :
ln -s nom_du_fichier_pointé nom_du_lien_symboliquePå Windows og bare på en NTFS- partisjon , opprettes symbolske lenker av tilstedeværelsen av / D-alternativet i en ledetekst ; det er imidlertid en inversjon mellom lenken og målet (i forhold til kommandoen ): ln
MKLINK /D nom_du_lien_symbolique nom_du_fichier_pointéSelv om rekkefølgen på argumentene ligner på cpog kommandoer mv, kan den vise seg å være kontraintuitiv: når rekkefølgen på parametrene reverseres ved en feiltagelse, blir lenken opprettet i den spisse katalogen, og blir referert til seg selv. ! Dette skjer når vi mentalt transponerer setningen "Jeg vil gå fra nom_du_symbolic_lien_name til nom_du_fichier_pointé " der rekkefølgen på elementene blir reversert. En annen kilde til forvirring er at hvis relative_linker, hvis name_du_symbolic_link ikke er plassert i gjeldende katalog, ikke name_du_file_pointed ikke angir filen som tilgjengelig fra den nåværende katalogen: name_du_file_pointed må løses fra katalogen der filen skal ligge.
Med GNU- versjonen av cper det mulig å lage en symbolsk lenke til en gitt fil på en mye mer intuitiv måte. Dette fungerer imidlertid ikke med kataloger, og for relative lenker må den symbolske lenken som skal opprettes være i den gjeldende katalogen. Siden dette ikke er POSIX , anbefales det ikke å bruke dette i et skript ( BSD- versjonen av cp, blant andre, støtter ikke dette alternativet):
cp -s nom_du_fichier_pointé nom_du_lien_symboliqueDe fleste operasjoner (lese, skrive, utføre) på en symbolsk lenke, refererer automatisk til den og opererer på målet (den faktiske filen). Sletting ( rm) eller flytt / endre navn ( mv) er knyttet til lenken og påvirker ikke filen.
En symbolsk lenke har alltid samme tilgangsrettigheter som filen den peker på. I virkeligheten er tilgangsrettighetene som er spesifisert for en symbolsk lenke meningsløse. Kommandoen chmodhenviser alltid filene som sendes til den som argumenter, og det er derfor ikke mulig å gi spesifikke tillatelser til den symbolske lenken.
Skjermkatalogens innholdskommando lsrepresenterer symbolske lenker som følger:
lrwxrwxrwx 1 root root 9 2005-08-26 21:47 python -> python2.3I lden første kolonnen indikerer at denne oppføringen er en symbolsk lenke. Helt til høyre på linjen vises egenskapene til denne symbolske lenken: når brukeren får tilgang til python , vil han bli omdirigert transparent av systemet til python2.3- versjonen . I dette eksemplet ble den symbolske lenken opprettet for å beholde flere versjoner (2.1, 2.2, 2.3, etc.) av Python-språket samtidig .
I motsetning til harde lenker , kan symbolske lenker peke på vanlige filer, kataloger, til seg selv eller til mål som ikke eksisterer (eksistensen av det spissede filnavnet blir ikke engang kontrollert når lenken er opprettet av kommandoen ln). Det er bare når du får tilgang til en symbolsk lenke at bekreftelsen er gjort. Når målet for en symbolsk lenke ikke eksisterer, sier vi at "lenken er ødelagt" ( ødelagt lenke , på engelsk). Et forsøk på å åpne en ødelagt lenke for lesing resulterer i en feilmelding "fil ikke funnet", noe som er ganske overraskende siden den symbolske lenken eksisterer.
Symbolske lenker kan være en kilde til ubehagelige overraskelser for nybegynnere, ettersom de gjør at en fil ser ut til å være til stede flere ganger i filsystemtreet . En sletting av målet som ble gjort under illusjonen om at den samme filen eksisterer andre steder (når de bare er lenker), fører deretter til permanent tap av filen og bryter øyeblikkelig alle symbolske lenker som pekte på den.
Noen gamle programmer , opprettet når lenkene ikke eksisterte, kan ha ganske katastrofale konsekvenser når de blir konfrontert med lenker, enten de er symbolske eller fysiske. I beste fall kan de falle i en endeløs sløyfe som prøver å følge et koblet tre på og av på ubestemt tid. I verste fall vil fjerning av en symbolsk lenke som peker til en katalog føre til at innholdet i den koblede katalogen fjernes. Heldigvis er Unix-styring av lenker ganske gammel, og det er lite sannsynlig at det kommer slike programmer. Dette forhindrer imidlertid ikke systemet fra å beskytte seg selv ved å forby for eksempel sletting av en symbolsk lenke som peker til en katalog ved hjelp av kommandoen rmdir(typisk oppførsel til et program som ikke er ment for lenker).
Tidlige implementeringer av symbolske lenker behandlet informasjon om den spisse filen som data fra en vanlig fil. Denne vanlige filen inneholdt bare tegnstrengen som representerer navnet på den spisse filen, og bare et flagg ba systemet ikke åpne denne filen, men den hvis navn ble angitt der.
Denne metoden har fordelen av å være enkel å utføre, men har likevel to ulemper. For det første åpner hver åpning av en fil via en symbolsk kobling faktisk to filer, og enda mer hvis selve filbanen består av symbolske lenker. Disse flere åpningene bremser systemet. For det andre, siden de få byte som trengs for å lagre navnet på den spisse filen, betraktes som en fil, tar de plassen til en full tildelingsenhet på disken , som kaster bort lagringsplass. Denne første implementeringen ble kalt retroactively slow symlink .
En evolusjon kalt rask symlink er både raskere og billigere i lagringskapasitet. Den består i å lagre tegnstrengen som representerer navnet på den spisse filen i en ekstra sone i inoden . Siden disse inneholder viktig filsysteminformasjon, brukes de ofte av systemet, som derfor opprettholder dem i hovedminnet for å sikre umiddelbar tilgang. Siden navnet på den spisse filen er en del av denne strukturen, har den også fordeler av denne raske minnetilgangen, noe som i høy grad øker dens referanse. Systemet kan imidlertid falle tilbake til den gamle (treg) metoden hvis lengden på strengen overstiger den begrensede lagringskapasiteten til en inode.