Hvorfor kan jeg ikke ændre ibrugtagne filer på Windows som jeg kan på Linux og OS X?
Når du bruger Linux og OS X, vil operativsystemet ikke stoppe dig fra at slette en fil, der aktuelt er i brug, men i Windows bliver du udtrykkeligt udelukket fra at gøre det. Hvad giver? Hvorfor kan du redigere og slette in-use-filer på Unix-afledte systemer, men ikke Windows?
Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.
Spørgsmålet
SuperUser-læser the.midget ønsker at vide, hvorfor Linux og Windows behandler ibrugtagne filer forskelligt:
En af de ting, der har forvirret mig lige siden jeg begyndte at bruge Linux, er, at det giver dig mulighed for at ændre navnet på en fil eller endda slette det, mens det læses. Et eksempel er, hvordan jeg ved et uheld forsøgte at slette en video, mens den spillede. Jeg lykkedes og blev overrasket, da jeg lærte at du kan ændre næsten alt i en fil uden at passe, om det bliver brugt i øjeblikket eller ej.
Så hvad sker der bag kulisserne og forhindrer ham i at slette ting i Windows, som han kan i Linux?
Svaret
SuperUser-bidragsydere kaster lys over situationen for the.midget. Forundret skriver:
Når du åbner eller udfører en fil i Windows, lås Windows filen på plads (dette er en forenkling, men det er normalt sandt.) En fil, der er låst ved en proces, kan ikke slettes, før processen frigiver den. Det er derfor, at når Windows skal opdatere sig selv, skal du genstarte, for at den skal træde i kraft.
På den anden side låser Unix-lignende operativsystemer som Linux og Mac OS X ikke filen, men snarere de underliggende disksektorer. Dette kan virke som en trivial differentiering, men det betyder, at filens rekord i filsystemets indholdsfortegnelse kan slettes uden at forstyrre noget program, der allerede har filen åben. Så du kan slette en fil, mens den stadig udføres eller på anden måde er i brug, og den vil fortsætte med at eksistere på disken, så længe en proces har et åbent håndtag til det, selv om dets indtastning i filtabellen er væk.
David Schwartz udvider ideen og fremhæver hvordan tingene skal være ideelt og hvordan de er i praksis:
Windows er standard til automatisk, obligatorisk fillåsning. UNIXes standard til manuel, kooperativ fillåsning. I begge tilfælde kan standardværdierne overstyres, men i begge tilfælde er de normalt ikke.
Meget gammel Windows-kode bruger C / C ++ API (funktioner som fopen) i stedet for den native API (funktioner som CreateFile). C / C ++ API'en giver dig ingen mulighed for at angive, hvordan obligatorisk låsning virker, så du får standardindstillingerne. Standard "share mode" har tendens til at forbyde "modstridende" operationer. Hvis du åbner en fil til skrivning, antages skrivninger at være konflikt, selvom du aldrig faktisk skriver til filen. Ditto til omnavne.
Og her er hvor det bliver værre. Ud over at åbne for læsning eller skrivning giver C / C ++ API ingen mulighed for at angive, hvad du har til hensigt at gøre med filen. Så API'en skal påtage sig, at du vil udføre enhver lovlig handling. Da låsningen er obligatorisk, vil en åben, der tillader en modstridende operation, blive nægtet, selvom koden aldrig har til hensigt at udføre den modstridende operation, men kun åbner filen til et andet formål.
Så hvis kode bruger C / C ++ API eller bruger den native API uden at tænke specifikt på disse problemer, vil de lukke op for at forhindre det maksimale sæt af mulige operationer for hver fil de åbner og ikke kan åbne en fil, medmindre enhver mulig operation de kunne udføre på det, når åbnet er ukonflikt.
Efter min mening ville Windows-metoden fungere meget bedre end UNIX-metoden, hvis hvert program valgte dets delemetoder og åbne tilstande klogt og sankt håndterede fejlfel. UNIX-metoden fungerer dog bedre, hvis kode ikke generer at tænke over disse problemer. Desværre placerer det grundlæggende C / C ++ API ikke godt på Windows-fil-API'en på en måde, der håndterer delingsmodi og modstridende åbnes godt. Så nettoresultatet er lidt rodet.
Der har du det: To forskellige tilgange til filhåndtering giver to forskellige resultater.
Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.
