Hvilken filtilstand er et symlink?

Filtilstande dækker to forskellige begreber: filtyper og filtilladelser. En fils tilstand er repræsenteret af værdien af st_mode i resultatet af stat(2) opkald og ls -l præsenterer dem alle sammen; se Forståelse af UNIX-tilladelser og filtyper for detaljer.

Når en fil er oprettet, kan dens type “ikke ændres. Derudover kan du ikke angive et symlink-tilladelse på Linux-systemer; alt, hvad der betyder noget, er målets tilladelse (og faktisk den fulde tilstand, da det også bestemmer symlinkets adfærd). Se Hvordan gælder filtilladelser for symlinks? for detaljer. På Mac OS X kan symlinks have deres egne tilladelser.

Endelig bruger git en forenklet model med et begrænset antal anerkendte tilstande:

• 040000 for en mappe
• 100644 for en normal fil
• 100755 for en eksekverbar fil
• 120000 for et symbolsk link

Du kan se disse værdier ved hjælp af kommandoer som git cat-file -p "master^{tree}"; se Pro Git for detaljer.

Hvilken filtilstand angiver, at en fil er et symbolsk link (symlink)?

POSIX API til kontrol hvis en fil er et symlink, bruger S_ISLNK makroen.

I glibc defineres S_ISLNK 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 et symlink if ((mode & 0170000) == 0120000) (i det mindste på GNU / Linux).

Et symlink (selvom nogle filsystemer håndterer symlinks anderledes) er en inode -tabelpost, der peger på det samme sted som en anden fil (eller bibliotek).

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

bar eksisterer det ikke virkelig, det er bare en markør til en “rigtig” fil.

Symlinks har generelt ikke tilladelser uden tilladelserne til den fil, de peger på. Så bar"s tilladelser er “det samme” as foo"s. Du kan ikke angive tilladelser til bar (symlinket) kun på foo (den rigtige fil).

Når det er sagt, er det “en virkelig høj visning. Forskellige filsystemer håndterer symlinks forskelligt. Forskellige værktøjer håndterer symlinks forskelligt. Nogle filsystemer” markerer “symlinks og håndter dem specielt, men nogle ikke.

For eksempel chmod på Linux vil ikke ændre en symlinks tilladelser, men på OSX kan du få det til. I begge tilfælde ændres de rigtige filers tilladelser.

Jeg kan ikke tænke på noget system (gør ikke t betyder det “er ikke derude), hvor en symlink har tilladelser adskilt fra den rigtige fil.

Kommentarer

• Nej, et symlink er en filtype (" alt er en fil "), der indeholder et filnavn i stedet for generelt- formålsdata. Typisk henviser dette filnavn til en eksisterende fil – at ' er hele pointen med symlinks – men dette er ikke garanteret at være sandt. Ja, et symlink (som alle andre filtype) har en inode. Nej, et symlink og den fil, det peger på, har separate inoder med forskellige inode-numre. Hard links har den samme inode og dermed den samme inode num ber.
• Nå, det var meningen, at det skulle være et højt niveau, men moderne systemer gør ' t opretter en fil på harddisken, inode-tabellen indeholder strengen, og der er ingen rigtig fil oprettet. Jeg tror, det hedder ' " hurtigt symlink "
• Hvis ' foo ' og ' bar ' er begge henvisninger til knude 1234, så er de ' HARDE links, ikke symlinks. Hvis " bar " var et SYMlink, ville det bogstaveligt talt være tegnstrengen " foo " (eller endda stien til foo) i stedet for en node. Faktisk kan du oprette et symlink, der ikke ' ikke peger hvor som helst meningsfuldt overhovedet, f.eks. ln -s 'this is not a real file' bar
• Også: BSD (som inkluderer Mac OS X) har et lchmod () systemopkald, der giver dig mulighed for at indstille tilladelserne til selve symlinket. Jeg aner ikke, hvad brugen af det er.