2024 Auteur: Peter John Melton | [email protected]. Laatst gewijzigd: 2023-12-16 04:43
De Question & Answer-sessie van vandaag komt naar ons met dank aan SuperUser, een onderafdeling van Stack Exchange, een door de gemeenschap gestuurde groep van Q & A-websites.
De vraag
SuperUser-lezer the.midget wil weten waarom Linux en Windows in-use-bestanden anders behandelen:
One of the things that has puzzled me ever since I started using Linux is the fact that it allows you to change the name of a file or even delete it while it is being read. An example is how I accidentally tried to delete a video while it was playing. I succeeded, and was surprised as I learnt that you can change just about anything in a file without caring if it’s being used at the moment or not.
Dus wat gebeurt er achter de schermen en voorkomt dat hij dingen in Windows zomaar laat verwijderen zoals hij dat in Linux kan doen?
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 pas worden verwijderd als 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 blokkeren Unix-achtige besturingssystemen zoals Linux en Mac OS X het bestand niet, maar de onderliggende schijfsectoren. Dit lijkt misschien een triviale differentiatie, maar het betekent dat de bestandsopname in de inhoudstabel van het bestandssysteem kan worden verwijderd zonder het programma te onderbreken dat het bestand al open heeft staan. 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 moeten zijn en hoe ze in de praktijk zijn:
Windows defaults to automatic, mandatory file locking. UNIXes default to manual, cooperative file locking. In both cases, the defaults can be overriden, but in both cases they usually aren’t.
A lot of old Windows code uses the C/C++ API (functions like fopen) rather than the native API (functions like CreateFile). The C/C++ API gives you no way to specify how mandatory locking will work, so you get the defaults. The default “share mode” tends to prohibit “conflicting” operations. If you open a file for writing, writes are assumed to conflict, even if you never actually write to the file. Ditto for renames.
And, here’s where it gets worse. Other than opening for read or write, the C/C++ API provides no way to specify what you intend to do with the file. So the API has to assume you are going to perform any legal operation. Since the locking is mandatory, an open that allows a conflicting operation will be refused, even if the code never intended to perform the conflicting operation but was just opening the file for another purpose.
So if code uses the C/C++ API, or uses the native API without specifically thinking about these issues, they will wind up preventing the maximum set of possible operations for every file they open and being unable to open a file unless every possible operation they could perform on it once opened is unconflicted.
In my opinion, the Windows method would work much better than the UNIX method if every program chose its share modes and open modes wisely and sanely handled failure cases. The UNIX method, however, works better if code doesn’t bother to think about these issues. Unfortunately, the basic C/C++ API doesn’t map well onto the Windows file API in a way that handles share modes and conflicting opens well. So the net result is a bit messy.
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 opmerkingen. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk de volledige discussiethread hier.
Aanbevolen:
Waarom zijn MOBA-games zoals League of Legends zo populair?
Multiplayer Online Battle Arenas, of MOBA's, verwijzen naar een zeer specifieke subset van top-down, teamgebaseerde strategietitels. Ondanks hun bescheiden begin als een gematigde uitloper van real-time strategiespellen, zijn deze titels ontploft in de voorhoede van pc-gaming, krijgen ze tientallen miljoenen spelers en een plekje aan de top van de eSports (blech *) wereld.
Waarom u geen Firefox-vorken zoals Waterfox, Pale Moon of Basilisk moet gebruiken
Mozilla Firefox is een open source-project, dus iedereen kan de code ervan overnemen, deze wijzigen en een nieuwe browser vrijgeven. Dat is wat Waterfox, Pale Moon en Basilisk zijn: alternatieve browsers op basis van de Firefox-code. Maar we raden aan om geen van deze te gebruiken.
Doen niet-Windows-platforms zoals Mac, Android, iOS en Linux virussen op?
Virussen en andere soorten malware lijken grotendeels beperkt te zijn tot Windows in de echte wereld. Zelfs op een Windows 8-pc kun je nog steeds geïnfecteerd raken met malware. Maar hoe kwetsbaar zijn andere besturingssystemen tegen malware?
Waarom kan Zip afzonderlijke bestanden comprimeren beter dan meerdere bestanden met dezelfde inhoud?
Doordat we onze bestanden kunnen comprimeren zodat ze gemakkelijker kunnen worden gedeeld en / of getransporteerd, kunnen onze elektronische levens veel eenvoudiger worden, maar soms kunnen we oneven of onverwachte dimensioneringsresultaten zien nadat we ze hebben gecomprimeerd. Waarom is dat? De SuperUser Q & A-post van vandaag biedt de antwoorden op de vragen van een verwarde lezer.
Je zou Linux-bestanden niet op Windows 10 moeten veranderen. Waarom?
Het maken of wijzigen van Linux-bestanden van Windows zal waarschijnlijk resulteren in datacorruptie en kan de Linux-omgeving beschadigen. Dit is waarom en hoe je dit kunt voorkomen.