Waarom kan ik de niet-gebruikte bestanden in Windows Like I Can niet wijzigen op Linux en OS X?

Wanneer u Linux en OS X gebruikt, houdt het besturingssysteem u er niet van weer een bestand te verwijderen dat momenteel in gebruik is, maar op Windows wordt dit uitdrukkelijk uitgesloten. Wat geeft? Waarom kunt u in gebruik zijnde bestanden op Unix-afgeleide systemen maar niet op Windows bewerken en verwijderen??

De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.

De vraag

SuperUser-lezer the.midget wil weten waarom Linux en Windows in-use-bestanden anders behandelen:

Een van de dingen die me heeft verbaasd sinds ik Linux begon te gebruiken, is het feit dat je hiermee de naam van een bestand kunt wijzigen of zelfs kunt verwijderen terwijl het wordt gelezen. Een voorbeeld is hoe ik per ongeluk probeerde een video te verwijderen terwijl deze aan het spelen was. Het is me gelukt en ik was verrast toen ik hoorde dat je zowat alles in een bestand kunt veranderen zonder er om te geven of het op dit moment wordt gebruikt of niet.

Dus wat gebeurt er achter de schermen en voorkomt dat hij dingen in Windows zomaar wegschrijft zoals hij kan in Linux?

Het antwoord

Bijdragers van SuperUser werpen enig licht op de situatie voor the.midget. Amazed schrijft:

Wanneer u een bestand in Windows opent of uitvoert, vergrendelt Windows het bestand (dit is een vereenvoudiging, maar meestal waar.) Een bestand dat is vergrendeld door een proces, kan niet worden verwijderd totdat dat proces het bestand vrijgeeft. Dit is de reden waarom telkens wanneer Windows zichzelf moet bijwerken, het opnieuw moet worden opgestart voordat dit van kracht wordt.

Aan de andere kant vergrendelen Unix-achtige besturingssystemen zoals Linux en Mac OS X het bestand niet, maar de onderliggende schijfsectoren. Dit lijkt een triviale differentiatie, maar het betekent dat de record van het bestand in de inhoudstabel van het bestandssysteem kan worden verwijderd zonder een programma te storen dat het bestand al open heeft staan. U kunt dus een bestand verwijderen terwijl het nog steeds wordt uitgevoerd of anderszins wordt gebruikt en het zal blijven bestaan ​​op de schijf zolang een proces een open ingang heeft, ook al is de invoer in de bestandstabel weg.

David Schwartz gaat dieper in op het idee en benadrukt hoe dingen idealiter moeten zijn en hoe ze in de praktijk zijn:

Windows is standaard ingesteld op automatische, verplichte bestandsvergrendeling. UNIXes is standaard ingesteld op handmatige, coöperatieve bestandsvergrendeling. In beide gevallen kunnen de standaardwaarden worden overschreven, maar in beide gevallen zijn ze dat meestal niet.

Veel oude Windows-code gebruikt de C / C ++ API (functies zoals fopen) in plaats van de native API (functies zoals CreateFile). De C / C ++ API geeft je geen manier om aan te geven hoe verplichte vergrendeling werkt, dus je krijgt de standaardinstellingen. De standaard "deelmodus" heeft de neiging om "conflicterende" bewerkingen te verbieden. Als u een bestand opent om te schrijven, wordt van schrijven aangenomen dat het conflicteert, zelfs als u nooit daadwerkelijk naar het bestand schrijft. Idem voor nieuwe namen.

En hier wordt het nog erger. Afgezien van openen voor lezen of schrijven, biedt de C / C ++ API geen mogelijkheid om op te geven wat u met het bestand wilt doen. Dus de API moet ervan uitgaan dat je een legale operatie gaat uitvoeren. Aangezien de vergrendeling verplicht is, wordt een open status die een conflicterende bewerking toestaat geweigerd, zelfs als de code nooit de bedoeling had de conflicterende bewerking uit te voeren, maar het bestand gewoon voor een ander doel opende.

Dus als code de C / C ++ API gebruikt, of de native API gebruikt zonder specifiek na te denken over deze problemen, zullen ze eindigen met het voorkomen van de maximale reeks mogelijke operaties voor elk bestand dat ze openen en niet in staat zijn om een ​​bestand te openen tenzij elke mogelijke bewerking zou kunnen uitvoeren als het eenmaal geopend is, is onbegaanbaar.

Naar mijn mening zou de Windows-methode veel beter werken dan de UNIX-methode als elk programma zijn deelmodi en open modi slim en met zorg afgehandeld had. De UNIX-methode werkt echter beter als code niet de moeite neemt om na te denken over deze problemen. Helaas komt de standaard C / C ++ API niet goed in de Windows-bestands-API op een manier die omgaat met deelmodi en conflicten goed opent. Het nettoresultaat is dus een beetje rommelig.

Daar heb je het: twee verschillende benaderingen voor bestandsafhandeling leveren twee verschillende resultaten op.

Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.