Hvorfor kan jeg ændre in-use-filer på Windows som jeg kan på Linux og OS X?

Indholdsfortegnelse:

Video: Hvorfor kan jeg ændre in-use-filer på Windows som jeg kan på Linux og OS X?

Video: Hvorfor kan jeg ændre in-use-filer på Windows som jeg kan på Linux og OS X?
Video: How to RUN Android APPS in Windows 10 with BLUE STACKS! 2024, Marts
Hvorfor kan jeg ændre in-use-filer på Windows som jeg kan på Linux og OS X?
Hvorfor kan jeg ændre in-use-filer på Windows som jeg kan på Linux og OS X?
Anonim
 Når du bruger Linux og OS X, har operativsystemet vundet. Jeg stopper dig fra at slette en fil, der i øjeblikket 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?
Når du bruger Linux og OS X, har operativsystemet vundet. Jeg stopper dig fra at slette en fil, der i øjeblikket 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 tilladelse til 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:

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.

Så hvad sker der bag scenerne 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 eksekverer en fil i Windows, lås Windows filen på plads (dette er en forenkling, men 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 filen 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 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.

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.

Anbefalede: