17Aug
När du använder Linux och OS X kommer operativsystemet inte att hindra dig från att radera en fil som är i bruk ännu, men i Windows kommer du uttryckligen att spärras från att göra det. Vad ger? Varför kan du redigera och ta bort användningsfiler på Unix-härledda system men inte Windows?
Dagens fråga &Svarssession kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.
Frågan
SuperUser-läsare the.midget vill veta varför Linux och Windows behandlar användningsfiler annorlunda:
En av de saker som har förbryllat mig ända sedan jag började använda Linux är det faktum att det låter dig ändra namnet påen fil eller till och med radera den medan den läses. Ett exempel är hur jag av misstag försökte ta bort en video medan den spelades. Jag lyckades och blev förvånad när jag lärde mig att du kan ändra nästan allt i en fil utan att ta hand om det används för tillfället eller inte.
Så vad händer bakom kulisserna och förhindrar att han vill ha borttagen saker i Windows som han kan i Linux?
Svaret
SuperUser-bidragsgivare kasta lite ljus på situationen för the.midget. Förvånad skriver:
När du öppnar eller kör en fil i Windows låser Windows filen på plats( det här är en förenkling, men vanligtvis sann.) En fil som är låst av en process kan inte raderas förrän den processen släpper ut den. Det är därför som Windows måste uppdatera sig behöver du en omstart för att den ska träda i kraft.
Å andra sidan låser Unix-liknande operativsystem som Linux och Mac OS X inte filen utan snarare de underliggande skivbranscherna. Detta kan verka som en trivial differentiering men det betyder att filens register i filsystemets innehållsförteckning kan raderas utan att störa något program som redan har filen öppen. Så du kan ta bort en fil medan den fortfarande körs eller används på annat sätt och den kommer att fortsätta att finnas på disk så länge som en del process har ett öppet handtag för det trots att dess inmatning i filtabellen är borta.
David Schwartz expanderar på idén och belyser hur saker ska vara idealiska och hur de är i praktiken:
Windows standardinställningar för automatisk, obligatorisk fillåsning. UNIXs standard till manuellt, kooperativ fillåsning. I båda fallen kan standardvärdena överskridas, men i båda fallen är de vanligtvis inte.
Mycket gammal Windows-kod använder C / C ++ API( funktioner som fopen) istället för det ursprungliga API-en( funktioner som CreateFile).C / C ++ API ger dig inget sätt att ange hur obligatorisk låsning fungerar, så du får standardinställningarna. Standard delningsläge tenderar att förbjuda "motstridiga" operationer. Om du öppnar en fil för skrivning antas skrivningar vara konflikt, även om du aldrig faktiskt skriver till filen. Ditto för byte namn.
Och här är det där det blir värre. Förutom att läsa eller skriva öppnar C / C ++ API inget sätt att ange vad du tänker göra med filen. Så API: n måste anta att du kommer att utföra någon juridisk operation. Eftersom låsningen är obligatorisk, kommer en öppning som tillåter en motstridande operation att vägras, även om koden aldrig skulle utföra den motstridiga operationen utan bara öppnade filen för ett annat syfte.
Så om kod använder C / C ++ API eller använder det inbyggda API utan att specifikt tänka på dessa problem kommer de att sluta förhindra maximal uppsättning möjliga operationer för varje fil de öppnar och inte kan öppna en fil om inte alla möjliga åtgärderde kunde utföra sig på det när de öppnas är otrolig.
Enligt min mening skulle Windows-metoden fungera mycket bättre än UNIX-metoden om varje program valde sina dellägen och öppna lägen klokt och sankt hanterade misslyckanden. UNIX-metoden fungerar dock bättre om kod inte stör att tänka på dessa problem. Tyvärr kartlägger det grundläggande C / C ++ API inte bra på Windows-fil API på ett sätt som hanterar delningslägen och motstridigt öppnas väl. Så nettoresultatet är lite rörigt.
Där har du det: två olika metoder för filhantering ger två olika resultat.
Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.