Låsning af filer - File locking

Fillåsning er en mekanisme, der begrænser adgangen til en computerfil eller til et område i en fil ved kun at tillade én bruger eller proces at ændre eller slette den på et bestemt tidspunkt og forhindre læsning af filen, mens den ændres eller slettes .

Systemer implementerer låsning for at forhindre det klassiske opdateringsscenario for interceding , som er et typisk eksempel på en race -tilstand , ved at håndhæve serieliseringen af ​​opdateringsprocesser til en given fil. Følgende eksempel illustrerer problem med opdateringsopdatering:

  1. Proces A læser en kunde rekord fra en fil, der indeholder kontooplysninger, herunder kundens konto balance og telefonnummer.
  2. Proces B læser nu den samme post fra den samme fil, så den har sin egen kopi.
  3. Proces A ændrer kontosaldoen i sin kopi af kundeposten og skriver posten tilbage til filen.
  4. Proces B, som stadig har den oprindelige forældede værdi for kontosaldoen i sin kopi af kundejournalen, opdaterer kontosaldoen og skriver kundejournalen tilbage til filen.
  5. Proces B har nu skrevet sin forældede kontosaldoværdi til filen, hvilket får de ændringer, der er foretaget af proces A til at gå tabt.

De fleste operativsystemer understøtter konceptet med registrering af lås , hvilket betyder, at individuelle poster i en given fil kan låses og derved øge antallet af samtidige opdateringsprocesser. Databasevedligeholdelse bruger fillåsning, hvorved den kan serialisere adgangen til hele den fysiske fil, der ligger til grund for en database. Selvom dette forhindrer enhver anden proces i at få adgang til filen, kan den være mere effektiv end individuelt at låse mange regioner i filen ved at fjerne omkostningerne ved at erhverve og frigive hver lås.

Dårlig brug af fillåse, ligesom enhver computer lås , kan resultere i dårlig ydelse eller i dødvande . Fillåsning kan også referere til yderligere sikkerhed, der anvendes af en computerbruger, enten ved hjælp af Windows -sikkerhed, NTFS -tilladelser eller ved at installere en tredjeparts fillåsningssoftware.

I mainframes

IBM var banebrydende for fillåsning i 1963 til brug i mainframe -computere ved hjælp af OS/360 , hvor det blev betegnet "eksklusiv kontrol".

I Microsoft Windows

Microsoft Windows bruger tre forskellige mekanismer til at administrere adgang til delte filer:

  1. ved hjælp af deleadgangskontroller, der gør det muligt for applikationer at angive adgang til deling af hele filer til læsning, skrivning eller sletning
  2. ved hjælp af byte-range-låse til at arbitrere læse- og skriveadgang til regioner inden for en enkelt fil
  3. ved at Windows -filsystemer forhindrer udførelse af filer i at blive åbnet til skrive- eller sletteadgang

Windows arver semantikken i dele-adgangskontroller fra MS-DOS- systemet, hvor deling blev introduceret i MS-DOS 3.3. Således skal et program eksplicit tillade deling, når det åbner en fil; ellers har den eksklusiv læse-, skrive- og sletteadgang til filen, indtil den lukkes (andre typer adgang, f.eks. dem, der skal hente attributter for en fil, er tilladt.)

For en fil, der åbnes med delt adgang, kan applikationer derefter bruge byte-range-låsning til at styre adgangen til bestemte områder af filen. Sådanne byte-områdelåse angiver et område af filen (forskydning og længde) og låsetypen (delt eller eksklusiv). Bemærk, at området for filen, der låses, ikke er påkrævet for at have data i filen, og applikationer udnytter undertiden denne evne til at implementere deres funktionalitet.

For applikationer, der bruger fil-læse/skrive- API'erne i Windows, håndhæves byte-range-låse (også kaldet obligatoriske låse ) af filsystemerne, der udføres i Windows. For applikationer, der bruger filtilknytnings- API'erne i Windows, håndhæves byte-range-låse ikke (kaldes også rådgivende låse. ) Byte-range-låsning kan også have andre bivirkninger på Windows-systemet. For eksempel vil Windows-fildelingsmekanismen typisk deaktivere caching af en fil på klientsiden af alle klienter, når byte-range-låse bruges af enhver klient. Klienten vil observere langsommere adgang, fordi læse- og skriveoperationer skal sendes til den server, hvor filen er gemt.

Forkert fejlhåndtering i et applikationsprogram kan føre til et scenario, hvor en fil er låst (enten ved hjælp af "del" -adgang eller med byte-range-fillåsning) og ikke kan tilgås af andre applikationer. I så fald kan brugeren muligvis gendanne filadgang ved manuelt at afslutte det funktionsfejlende program. Dette gøres typisk via værktøjet Task Manager .

Den deling tilstand (dwShareMode) parameter for CreateFilefunktionen (bruges til at åbne filer) bestemmer fildeling. Deltilstanden kan angives for at tillade deling af filen til læsning, skrivning eller sletning af adgang eller enhver kombination af disse. Efterfølgende forsøg på at åbne filen skal være kompatibel med al tidligere givet delingstilgang til filen. Når filen lukkes, justeres restriktioner for deling af adgang for at fjerne de begrænsninger, som den specifikke fil åbner.

Byte-område låsningstype bestemmes af dwFlagsparameteren i den LockFileExfunktion, der bruges til at låse et område af en fil. Den Windows API -funktionen LockFilekan også bruges, og erhverver en eksklusiv lås på det område af filen.

Enhver fil, der indeholder en eksekverbar programfil, der i øjeblikket kører på computeren systemet som et program (fx en EXE, COM, DLL, CPLeller et andet binært program filformat) normalt låst af selve operativsystemet, forhindrer enhver applikation i at ændre eller slette den. Ethvert forsøg på at gøre det vil blive nægtet med en delingsfejl, på trods af at programfilen ikke åbnes af nogen applikation. Dog er en vis adgang stadig tilladt. For eksempel kan en kørende applikationsfil omdøbes eller kopieres (læses), selv når den udføres.

Filer åbnes af programmer i Windows ved hjælp af filhåndtag . Disse filhåndtag kan udforskes med hjælpeprogrammet Process Explorer . Dette værktøj kan også bruges til at tvinge lukke håndtag uden at skulle afslutte applikationen, der holder dem. Dette kan forårsage en udefineret adfærd, da programmet vil modtage en uventet fejl ved brug af det kraftlukkede håndtag og måske endda fungere på en uventet fil, da håndtagets nummer kan genbruges.

Microsoft Windows XP og Server 2003 -udgaver har introduceret kapacitet til snapshot ( VSS) af volumen til NTFS , hvilket gør det muligt at få adgang til åbne filer via backup -software på trods af eksklusive låse. Imidlertid, medmindre software er omskrevet til specifikt at understøtte denne funktion, vil snapshot'et kun være crash -konsekvent , mens korrekt understøttede applikationer kan hjælpe operativsystemet med at oprette "transaktionelt konsekvente" snapshots. Anden kommerciel software til adgang til låste filer under Windows inkluderer File Access Manager og Open File Manager . Disse fungerer ved at installere deres egne drivere for at få adgang til filerne i kernetilstand .

I Unix-lignende systemer

Unix-lignende operativsystemer (herunder Linux og Apples macOS ) låser normalt ikke automatisk åbne filer. Flere slags fillåsemekanismer er tilgængelige i forskellige varianter af Unix, og mange operativsystemer understøtter mere end én slags for kompatibilitet. Den mest almindelige mekanisme er fcntl. To andre sådanne mekanismer er flock(2)og lockf(3), som kan være adskilte eller kan implementeres oven på fcntl. Selvom nogle typer låse kan konfigureres til at være obligatoriske, er fillåse under Unix som standard rådgivende . Det betyder, at samarbejdende processer kan bruge låse til at koordinere adgang til en fil indbyrdes, men ikke -samarbejdende processer er også gratis til at ignorere låse og få adgang til filen på enhver måde, de vælger. Med andre ord låser fillåse kun andre filskabe, ikke I/O.

Der tilbydes to slags låse: delelåse og eksklusive låse. I tilfælde af fcntlkan forskellige slags låse anvendes på forskellige sektioner (byteområder) af en fil, eller også på hele filen. Delte låse kan holdes af flere processer på samme tid, men en eksklusiv lås kan kun holdes af en proces og kan ikke sameksistere med en delt lås. For at erhverve en delt lås skal en proces vente, indtil ingen processer indeholder nogen eksklusive låse. For at erhverve en eksklusiv lås skal en proces vente, indtil ingen processer indeholder nogen form for lås. I modsætning til låse fcntl, der er oprettet af flock, bevares de, der er oprettet af på tværs af forks, hvilket gør dem nyttige i forking -servere. Det er derfor muligt for mere end én proces at holde en eksklusiv lås på den samme fil, forudsat at disse processer deler et filialt forhold, og den eksklusive lås oprindeligt blev oprettet i en enkelt proces, før de blev kopieret på tværs af en fork.

Delte låse kaldes undertiden "læselåse", og eksklusive låse kaldes undertiden "skrivelåse". Fordi låse på Unix er rådgivende, håndhæves dette imidlertid ikke. Således er det muligt for en database at have et begreb om "delt skriver" vs. "eksklusive skriver"; for eksempel kan det være tilladt at ændre et felt på plads under delt adgang, hvorimod skraldespand og omskrivning af databasen kan kræve eksklusiv adgang.

Fillåse gælder for den faktiske fil i stedet for filnavnet. Dette er vigtigt, da Unix tillader flere navne at referere til den samme fil. Sammen med ikke-obligatorisk låsning fører dette til stor fleksibilitet i adgang til filer fra flere processer. På den anden side kan kooperativ låsemetode føre til problemer, når en proces skriver til en fil uden at adlyde fillåse, der er angivet af andre processer.

Af denne grund tilbyder nogle Unix-lignende operativsystemer også begrænset support til obligatorisk låsning . På sådanne systemer vil en fil, hvis setgidbit er tændt, men hvis gruppeudførelsesbit er slukket, når filen åbnes, automatisk blive obligatorisk låst, hvis det underliggende filsystem understøtter det. Imidlertid har ikke-lokale NFS-partitioner en tendens til at se bort fra denne bit. Hvis en fil er omfattet af obligatorisk låsning, blokeres forsøg på at læse fra et område, der er låst med en eksklusiv lås, eller at skrive til et område, der er låst med en delt eller eksklusiv lås, indtil låsen frigives. Denne strategi stammer først fra System V og kan ses i dag i operativsystemerne Solaris , HP-UX og Linux. Det er dog ikke en del af POSIX, og BSD-afledte operativsystemer som FreeBSD , OpenBSD , NetBSD og Apples macOS understøtter det ikke. Linux understøtter også obligatorisk låsning via den særlige -o mandparameter til filsystemmontering ( mount(8)), men dette bruges sjældent.

Nogle Unix-lignende operativsystemer forhindrer forsøg på at åbne den eksekverbare fil for et kørende program til skrivning; dette er en tredje form for låsning, adskilt fra dem, der leveres af fcntlog flock.

Problemer

Mere end én proces kan indeholde en eksklusiv flockfor en given fil, hvis den eksklusive lås blev kopieret på et senere tidspunkt fork. Dette forenkler kodning til netværksservere og hjælper med at forhindre løbeforhold, men kan være forvirrende for de uvidende.

Obligatoriske låse har ingen effekt på unlinksystemopkaldet. Derfor kan visse programmer effektivt omgå obligatorisk låsning. Stevens & Rago (2005) bemærkede, at edredaktøren faktisk gjorde det.

Hvorvidt og hvordan flocklåse fungerer på netværksfilsystemer, såsom NFS , er implementeringsafhængig. På BSD- systemer er flockopkald til en filbeskrivelse, der er åben for en fil på en NFS-monteret partition, vellykkede no-ops . På Linux før 2.6.12 ville flockopkald til NFS -filer kun handle lokalt. Kernel 2.6.12 og nyere implementerer flockopkald på NFS-filer ved hjælp af POSIX byte-range-låse. Disse låse vil være synlige for andre NFS -klienter, der implementerer POSIX -låse ifcntl stil , men usynlige for dem, der ikke gør det.

Lås opgraderinger og nedgraderinger frigiver den gamle lås, før du anvender den nye lås. Hvis en applikation nedgraderer en eksklusiv lås til en delt lås, mens en anden applikation er blokeret og venter på en eksklusiv lås, kan sidstnævnte applikation få den eksklusive lås og låse den første applikation ud. Det betyder, at låse-nedgraderinger kan blokere, hvilket kan være kontra-intuitivt.

Alle fcntl låse, der er knyttet til en fil til en given proces, fjernes, når en hvilken som helst filbeskrivelse for den pågældende fil lukkes af denne proces, selvom der aldrig blev anmodet om en lås for den pågældende filbeskrivelse. Desuden fcntler låser ikke arves af et barn proces. Den fcntltætte semantik er særlig besværlig for applikationer, der kalder subrutinebiblioteker, der kan få adgang til filer. Ingen af ​​disse "fejl" opstår ved hjælp af flocklåse i ægte stil.

Bevaring af låsestatus på åbne filbeskrivere, der overføres til en anden proces ved hjælp af et Unix -domæne -stik, er implementeringsafhængig.

Bufrede I/O -problemer

En kilde til låsefejl opstår, når bufferet I/O har buffere tildelt i brugerens lokale arbejdsområde i stedet for i en operativsystembufferpulje. freadog fwritebruges sædvanligvis til at lave bufferet I/O, og når først et afsnit af en fil er læst, vil et andet forsøg på at læse det samme afsnit højst sandsynligt få dataene fra den lokale buffer. Problemet er, at en anden bruger, der er knyttet til den samme fil, har deres egne lokale buffere, og det samme sker for dem. En fwriteaf data, der er hentet fra bufferen ved, freadvil ikke være at hente dataene fra selve filen, og en anden bruger kunne have ændret dem. Begge kan bruges flocktil eksklusiv adgang, hvilket forhindrer samtidige skrivninger, men da læsningerne læser fra bufferen og ikke selve filen, kan alle data ændret af bruger #1 gå tabt af bruger #2 (overskrevet). Den bedste løsning på dette problem er at bruge ikke -bufret I/O ( readog write) med flock, hvilket også betyder at bruge i lseekstedet for fseekog ftell. Selvfølgelig skal du foretage justeringer for funktionsparametre og returnerede resultater. Generelt er bufferet I/O usikkert, når det bruges med delte filer.

I AmigaOS

I AmigaOS kan en lås på en fil (eller bibliotek) erhverves ved hjælp af Lockfunktionen (i dos.library). En lås kan deles (andre processer kan læse filen/biblioteket, men kan ikke ændre eller slette den) eller eksklusiv, så kun den proces, der med succes erhverver låsen, kan få adgang til eller ændre objektet. Låsen er på hele objektet og ikke en del af det. Låsen skal frigives med UnLockfunktionen: I modsætning til i Unix låser operativsystemet ikke implicit op objektet, når processen afsluttes.

Lås filer

Shell -scripts og andre programmer bruger ofte en strategi, der ligner brugen af ​​fillåsning: oprettelse af låsefiler , som er filer, hvis indhold er irrelevant (selvom man ofte finder procesidentifikatoren for indehaveren af ​​låsen i filen), og hvis eneste formål er at signalere ved deres tilstedeværelse, at en eller anden ressource er låst. En låsfil er ofte den bedste fremgangsmåde, hvis den ressource, der skal kontrolleres slet ikke er en almindelig fil, så brug af metoder til låsning af filer gælder ikke. For eksempel kan en låsfil styre adgangen til et sæt relaterede ressourcer, f.eks. Flere forskellige filer, mapper, en gruppe diskpartitioner eller valgt adgang til protokoller på højere niveau, f.eks. Servere eller databaseforbindelser.

Når du bruger låsefiler, skal du være omhyggelig med at sikre, at operationerne er atomiske . For at opnå en lås skal processen verificere, at låsefilen ikke findes og derefter oprette den, samtidig med at en anden proces forhindres i at oprette den i mellemtiden. Forskellige metoder til at gøre dette omfatter:

  • Brug af lockfilekommandoen (en betinget semafor-filopretter distribueret i procmailpakken).
  • Systemopkald, der opretter en fil, men mislykkes, hvis filen allerede findes. (Systemopkald er tilgængelige fra sprog som C eller C ++, og shell -scripts kan gøre brug af noclobber )
  • Brug af mkdirkommandoen og kontroller udgangskoden for fejl

Låsfiler navngives ofte med et tilde ( ~) foran navnet på den fil, de låser, eller en duplikat af det fulde filnavn efterfulgt af .LCK . Hvis de låser en anden ressource end en fil, kan de navngives mere vilkårligt.

Visse Mozilla -produkter (f.eks. Firefox , Thunderbird, Sunbird) bruger denne type filressourcelåsemekanisme (ved hjælp af en midlertidig fil med navnet "parent.lock".)

Unlocker software

En unlocker er et værktøj, der bruges til at bestemme, hvilken proces der låser en fil, og viser en liste over processer samt valg om, hvad der skal gøres med processen (dræb opgave, lås op osv.) Sammen med en liste over filindstillinger som f.eks. slette eller omdøbe. På nogle Unix-lignende systemer kan hjælpeprogrammer som f.eks. fstatOg lockfbruges til at inspicere tilstanden for fillåse efter proces, filnavn eller begge dele.

Hvis en fil er låst på Windows -systemer, er det muligt at planlægge flytning eller sletning, der skal udføres ved den næste genstart. Denne fremgangsmåde bruges typisk af installatører til at erstatte låste systemfiler.

Versionsstyringssystemer

I versionskontrolsystemer bruges fillåsning til at forhindre to brugere i at ændre den samme filversion parallelt, og derefter ved at gemme den anden bruger til at overskrive, hvad den første bruger ændrede. Dette implementeres ved at markere låste filer som skrivebeskyttet i filsystemet. En bruger, der ønsker at ændre filen, udfører en oplåsning (også kaldet checkout), og indtil en check-in (butik) handling er udført, eller låsen er vendt tilbage, må ingen andre låse filen op.

Se også

Referencer

eksterne links