Täna, see küsimuste ja vastuste seanss tuleb meile viisakalt Super-kasutaja, Stowe Exchange'i alamrubriigist, Q & A veebisaitide kogukonnapõhiseks rühmituseks.
Küsimus
SuperUseri lugeja the.Midget soovib teada, miks Linux ja Windows käsitlevad kasutusel olevaid faile erinevalt:
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.
Nii et mis toimub stseenide taga ja takistab tal Windowsi asjadest loobumatut kustutamist, nagu ta saab Linuxis?
Vastus
SuperUseri toetajad teevad mõningast valgust mündi olukorra kohta. Amazed kirjutab:
Iga kord, kui avate või käivate faili Windowsis, lukustab Windows faili oma kohale (see on lihtsustamine, kuid tavaliselt tõsi). Faili, mis on protsessi lukustatud, ei saa kustutada, kuni see protsess seda ei vabasta. Sellepärast peab alati, kui Windows peab ise oma värskendama, reboot, et see jõustuks.
Teisest küljest ei luba Unix-tüüpi operatsioonisüsteemid, nagu Linux ja Mac OS X, faili lukustama, vaid pigem aluseks olevaid ketta sektoreid. See võib tunduda tühine diferentseerimine, kuid see tähendab, et failisüsteemi sisukorras olevat faili saab kustutada, ilma et see häiriks ühtki programmi, millel on juba avatud fail. Nii saate faili kustutada, kui see on ikka veel käivitatav või muul viisil kasutusel, ja see jätkub kettale olemasoluks, kui mõnel protsessil on avatud käepide, kuigi selle faili lahtrisse sisenemine on kadunud.
David Schwartz laiendab ideed ja tõstab esile, kuidas asjad peaksid olema ideaalsed ja kuidas nad praktikas toimivad:
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.
Seal on see: kaks erinevat lähenemist failide käsitsemisele annavad kaks erinevat tulemust.
Kas teil on seletamiseks midagi lisada? Helistage kommentaarides. Kas soovite lugeda rohkem vastuseid teistelt tech-savvy Stack Exchange'i kasutajatelt? Tutvu täieliku arutelu teemaga siit.
