Hvorfor kan jeg ikke endre bruk av filer på Windows som jeg kan på Linux og OS X?
Når du bruker Linux og OS X, vil operativsystemet ikke stoppe deg fra å slette en fil som er i bruk ennå, men i Windows blir du eksplisitt sperret fra å gjøre det. Hva gir? Hvorfor kan du redigere og slette i bruk filer på Unix-avledede systemer, men ikke Windows?
Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.
Spørsmålet
SuperUser-leser the.midget vil vite hvorfor Linux og Windows behandler filer som er i bruk, annerledes:
En av de tingene som har forvirret meg helt siden jeg begynte å bruke Linux, er at du kan endre navnet på en fil eller til og med slette den mens den leses. Et eksempel er hvordan jeg ved et uhell forsøkte å slette en video mens den spilte. Jeg lyktes, og ble overrasket da jeg lærte at du kan endre omtrent alt i en fil uten å bry deg om det blir brukt for øyeblikket eller ikke.
Så hva skjer bak kulissene og hindrer ham i å slette ting i Windows som han kan, i Linux?
Svaret
SuperUser-bidragsytere kaster litt lys på situasjonen for the.midget. Forundret skriver:
Når du åpner eller kjører en fil i Windows, låser Windows filen på plass (dette er en forenkling, men vanligvis sant.) En fil som er låst av en prosess kan ikke slettes før prosessen slipper den. Dette er grunnen til at når Windows må oppdatere seg selv, trenger du en omstart for at den skal tre i kraft.
På den annen side låser Unix-lignende operativsystemer som Linux og Mac OS X ikke filen, men heller de underliggende disksektorene. Dette kan virke som en triviell differensiering, men det betyr at filens rekord i filsystemets innholdsfortegnelse kan slettes uten å forstyrre et program som allerede har filen åpen. Så du kan slette en fil mens den fortsatt utføres eller på annen måte brukes, og den vil fortsette å eksistere på disk så lenge noen prosess har et åpent håndtak for det selv om oppføringen i filtabellen er borte.
David Schwartz utvider seg på ideen og fremhever hvordan ting skal være ideelt og hvordan de er i praksis:
Windows standard til automatisk, obligatorisk fillåsing. UNIXes standard til manuell, kooperativ fillåsing. I begge tilfeller kan standardene overstyres, men i begge tilfeller er de vanligvis ikke.
En masse gammel Windows-kode bruker C / C ++ API (funksjoner som fopen) i stedet for den native API (fungerer som CreateFile). C / C ++ API gir deg ingen måte å spesifisere hvordan obligatorisk låsing vil fungere, slik at du får standardinnstillingene. Standard "delmodus" har en tendens til å forby "konflikt" -operasjoner. Hvis du åpner en fil for skriving, antas det at skriveren er konflikt, selv om du aldri faktisk skriver til filen. Ditto for å gi nytt navn.
Og her er hvor det blir verre. Annet enn å åpne for å lese eller skrive, gir C / C ++ API ingen måte å spesifisere hva du har til hensikt å gjøre med filen. Så API-en må anta at du skal utføre enhver juridisk operasjon. Siden låsingen er obligatorisk, vil en åpen som tillater en motstridende operasjon bli nektet, selv om koden aldri har til hensikt å utføre den motstridende operasjonen, men bare åpnet filen til en annen hensikt.
Så hvis kode bruker C / C ++ API eller bruker den native API uten å tenke spesielt på disse problemene, vil de ende opp med å forhindre det maksimale settet av mulige operasjoner for hver fil de åpner og ikke kan åpne en fil med mindre alle mulige operasjoner de kunne utføre på det når åpnet er ukonflikt.
Etter min mening ville Windows-metoden fungere mye bedre enn UNIX-metoden hvis hvert program valgte sine delemoduser og åpne moduser klokt og sanitært håndtert feilfall. UNIX-metoden virker imidlertid bedre hvis kode ikke bryder seg om å tenke på disse problemene. Dessverre kartlegger den grunnleggende C / C ++ API ikke godt inn på Windows-fil-APIen på en måte som håndterer delmoduser og motstridende åpnes godt. Så nettoresultatet er litt rotete.
Der har du det: To forskjellige tilnærminger til filhåndtering gir to forskjellige resultater.
Har du noe å legge til forklaringen? Lyde av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.
