17Aug
Wanneer u Linux en OS X gebruikt, zal het besturingssysteem u er niet van weerhouden een bestand te verwijderen dat momenteel in gebruik is, maar op Windows wordt dit uitdrukkelijk uitgesloten. Wat geeft? Waarom kunt u in-gebruik-bestanden bewerken en verwijderen op Unix-afgeleide systemen maar niet op Windows?
De vraag van vandaag &Antwoord sessie komt naar ons met dank aan SuperUser-een onderverdeling van Stack Exchange, een community-gestuurde groepering 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 verbaasden sinds ik Linux begon te gebruiken, is het feit dat je hiermee de naam vaneen bestand of zelfs 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 laat verwijderen zoals hij dat in Linux kan doen?
De antwoorden
SuperUser-bijdragers werpen enig licht op de situatie voor the.midget. Verbaasd 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 het 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. U kunt dus een bestand verwijderen terwijl het nog bezig is of anderszins in gebruik is en het zal blijven bestaan op schijf zolang een proces er een open handle voor heeft, ook al is zijn invoer in de bestandstabel verdwenen.
David Schwartz breidt het idee uit en benadrukt hoe dingen idealiter en hoe ze in de praktijk moeten zijn:
Windows standaard naar automatische, verplichte bestandsvergrendeling. UNIXen zijn standaard ingesteld op handmatige, coöperatieve bestandsvergrendeling. In beide gevallen kunnen de standaardwaarden overschreven worden, 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. De API moet dus aannemen dat u een juridische bewerking gaat uitvoeren. Aangezien de vergrendeling verplicht is, wordt een open status die een conflicterende bewerking toestaat geweigerd, zelfs als de code nooit bedoeld was om de conflicterende bewerking uit te voeren, maar het bestand juist 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 set van mogelijke operaties voor elk bestand dat ze openen en niet in staat zijn om een bestand te openen, tenzij elke mogelijke bewerkingze kunnen erop spelen als het eenmaal is geopend, is niet gecompliceerd.
Naar mijn mening zou de Windows-methode veel beter werken dan de UNIX-methode als elk programma zijn deelmodi en open modi slim en goed behandelde foutgevallen koos. De UNIX-methode werkt echter beter als code niet de moeite neemt om na te denken over deze problemen. Helaas komt de basis-C / C ++ API niet goed in de Windows-bestands-API op een manier die deelnamemodi verwerkt en conflicten goed worden geopend. Het nettoresultaat is dus een beetje rommelig.
Daar heb je het: twee verschillende benaderingen voor bestandsafhandeling leveren twee verschillende resultaten op.
Heeft u iets toe te voegen aan de uitleg? Geluid uit in de opmerkingen. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk de volledige discussiethread hier.
