Hvilken filmodus er en symlink?

Filmodus dekker to forskjellige forestillinger: filtyper og filtillatelser. En fils modus er representert av verdien til st_mode i resultatet av stat(2) samtaler, og ls -l presenterer dem alle sammen; se Forstå UNIX-tillatelser og filtyper for detaljer.

Når en fil er opprettet, kan dens type kan ikke endres. I tillegg kan du på Linux-systemer ikke spesifisere en symlink-tillatelse; alt som betyr noe er målets tillatelse (og effektivt fullmodus siden det også bestemmer symlinkens oppførsel). Se Hvordan gjelder filtillatelser for symlinker? for detaljer. På Mac OS X kan symlenker ha sine egne tillatelser.

Til slutt bruker git en forenklet modell, med et begrenset antall anerkjente moduser:

• 040000 for en katalog
• 100644 for en normal fil
• 100755 for en kjørbar fil
• 120000 for en symbolsk lenke

Du kan se disse verdiene ved hjelp av kommandoer som git cat-file -p "master^{tree}"; se Pro Git for detaljer.

Hvilken filmodus indikerer at en fil er en symbolsk lenke (symlink)?

POSIX API for å sjekke hvis en fil er en symlink bruker S_ISLNK makroen.

I glibc er S_ISLNK definert som følger:

#define __S_IFMT 0170000 /* These bits determine file type. */ #define __S_IFLNK 0120000 /* Symbolic link. */ #define __S_ISTYPE(mode, mask) (((mode) & __S_IFMT) == (mask)) #define S_ISLNK(mode) __S_ISTYPE((mode), __S_IFLNK) 

dvs. en fil er en symlink if ((mode & 0170000) == 0120000) (i det minste på GNU / Linux).

En symlink (selv om noen filsystemer håndterer symlinker på en annen måte) er en inode tabelloppføring som peker til samme sted som en annen fil (eller katalog).

For eksempel hvis foo er inode 1234 så bar (a symlink til foo) er inode 1234.

bar eksisterer ikke det, det er bare en peker til en «ekte» fil.

Symlinks har generelt ikke tillatelser utenfor tillatelsene til filen de peker på. Så bar"s tillatelser er «det samme» as foo"s. Du kan ikke angi tillatelser på bar (symlinket) bare på foo (den virkelige filen).

Når det er sagt, er det «et veldig høyt nivå. Ulike filsystemer håndterer symlinker forskjellig. Ulike verktøy håndterer symlinks forskjellig. Noen filsystemer» flagg «symlinks og håndter dem spesielt, men noen ikke.

For eksempel chmod på Linux vil ikke endre en symlinks tillatelser, men på OSX kan du få det til. I begge tilfeller endres tillatelsene til de virkelige filene.

Jeg kan ikke tenke på noe system (ikke mener det «ikke er der ute) der en symlink har tillatelser atskilt fra den virkelige filen.

Kommentarer

• Nei, en symlink er en filtype (" alt er en fil ") som inneholder et filnavn i stedet for generelt- Formålsdata. Vanligvis refererer dette filnavnet til en eksisterende fil – at ' er hele poenget med å ha symlinker – men dette er garantert ikke sant. Ja, en symlink (som alle andre filtype) har en inode. Nei, en symlink og filen den peker på har separate inoder, med forskjellige inodetall. Hard lenker har samme inode, og dermed samme inode num ber.
• vel, det var ment å være høyt nivå, men moderne systemer lager ikke ' for å lage en fil på harddisken. Inodetabellen inneholder strengen og ingen reell fil er opprettet. Jeg tror det ' heter " rask symlink "
• Hvis ' foo ' og ' bar ' er begge pekepinner til node 1234, da ' er HARDE lenker, ikke symlinker. Hvis " bar " var en SYMlink, ville det bokstavelig talt være tegnstrengen " foo " (eller til og med banen til foo) i stedet for en node. Faktisk kan du opprette en symlink som ikke ' ikke peker hvor som helst meningsfull i det hele tatt, f.eks. ln -s 'this is not a real file' bar
• Også: BSD (som inkluderer Mac OS X) har en lchmod () systemanrop som lar deg stille inn tillatelsene til selve symlinket. Jeg aner ikke hva bruken av det er.