Miért nem tudom megváltoztatni a használatban lévő fájlokat a Windows-on, mint én is Linuxon és OS X-en?

Amikor Linuxot és OS X-et használ, az operációs rendszer nem fogja megakadályozni, hogy törölje a Windows rendszerben jelenleg használt fájlt. Mi ad? Miért szerkesztheti és törölheti a használatban lévő fájlokat Unix-alapú rendszereken, de nem a Windows-on?

A mai Kérdések és válaszok munkamenet a Jóvagyon - a Stack Exchange alosztályának, a közösség által vezérelt Q&A webhelyek csoportjának köszönhetően..

A kérdés

A SuperUser olvasó the.midget tudni akarja, hogy miért kezelik a Linux és a Windows a használatban lévő fájlokat másképpen:

Az egyik dolog, ami engem megzavarodott, mióta elkezdtem használni a Linuxot, az, hogy lehetővé teszi a fájl nevének megváltoztatását, vagy akár az olvasás közbeni törlését is. Példa erre, hogy véletlenül megpróbáltam törölni egy videót játék közben. Sikerült, és meglepődtem, amikor megtudtam, hogy bármit megváltoztathatsz egy fájlban gondozás nélkül, ha azt jelenleg használják vagy sem.

Tehát mi történik a színfalak mögött, és megakadályozza, hogy a Windowsban olyan dolgokat töröljen, mint amilyen a Linuxon?

A válasz

A SuperUser közreműködői rávilágítottak a helyszínre. Csodálatosan írja:

Amikor megnyit vagy futtat egy fájlt a Windows rendszerben, a Windows zárolja a fájlt (ez egy egyszerűsítés, de általában igaz.) A folyamat által zárolt fájl csak akkor törölhető, amíg a folyamat el nem engedi. Éppen ezért, ha a Windows-nak magának frissítenie kell, újraindításra van szüksége ahhoz, hogy hatályba lépjen.

Másrészt, a Unix-szerű operációs rendszerek, mint a Linux és a Mac OS X nem zárják le a fájlt, hanem a mögöttes lemezszektorokat. Ez triviális megkülönböztetésnek tűnhet, de ez azt jelenti, hogy a fájlrendszer tartalomjegyzékének rekordja törölhető anélkül, hogy megzavarná a már megnyitott fájlt. Így törölhet egy fájlt, miközben még fut, vagy más módon használják, és továbbra is létezik a lemezen, amíg bizonyos folyamatok nyitott fogantyúval rendelkeznek, annak ellenére, hogy a fájltáblázatban szereplő bejegyzése eltűnt.

David Schwartz bővíti az ötletet, és rávilágít arra, hogy a dolgok ideálisak legyenek, és hogyan működnek a gyakorlatban:

A Windows alapértelmezés szerint automatikus, kötelező fájlzárolás. UNIXes alapértelmezés szerint kézi, kooperatív fájlzárolás. Mindkét esetben az alapértelmezett értékek felülbírálhatók, de mindkét esetben általában nem.

Sok régi Windows-kód a C / C ++ API-t használja (mint például a fopen), mint a natív API-t (olyan funkciók, mint a CreateFile). A C / C + + API nem ad semmilyen módot arra, hogy meghatározza a kötelező zárolás működését, így az alapértelmezett értékeket kapja. Az alapértelmezett „megosztási mód” általában tiltja az „ütköző” műveleteket. Ha megnyit egy fájlt az íráshoz, akkor azt írják, hogy konfliktusba kerülnek, még akkor is, ha soha nem írsz a fájlba. Adja át a neveket.

És itt van, ahol rosszabbodik. A C / C ++ API az olvasási vagy írási megnyitáson kívül semmilyen módon nem határozza meg, hogy mit kíván tenni a fájlban. Tehát az API-nak feltételeznie kell, hogy bármilyen jogi műveletet hajt végre. Mivel a zárolás kötelező, az ütköző műveletet lehetővé tevő nyílást megtagadják, még akkor is, ha a kód nem szándékozik végrehajtani az ütköző műveletet, hanem csak egy másik célra nyitotta meg a fájlt.

Tehát, ha a kód a C / C ++ API-t használja, vagy a natív API-t használja, anélkül, hogy kifejezetten gondolnánk ezekre a problémákra, akkor megakadályozzák, hogy minden megnyitott fájl maximálisan beállítható legyen, és nem tudja megnyitni a fájlt, kivéve ha minden lehetséges művelet ha megnyitották, akkor nem lehet megdöbbenteni.

Véleményem szerint a Windows-módszer sokkal jobban működne, mint az UNIX-módszer, ha minden program kiválasztja a megosztási módjait és a nyitott módokat bölcsen és szándékosan kezelt hibaüzenetekkel. Az UNIX módszer azonban jobban működik, ha a kód nem zavarja ezeket a problémákat. Sajnos az alap C / C ++ API nem jól térképezi fel a Windows fájl API-t olyan módon, hogy kezelje a megosztási módokat és az ütközők jól megnyílnak. Tehát a nettó eredmény egy kicsit rendetlen.

Itt van: a fájlkezelés két különböző megközelítése két különböző eredményt eredményez.

Van valami, amit hozzá kell adni a magyarázathoz? Kikapcsolja a megjegyzéseket. Szeretne további válaszokat olvasni más tech-savvy Stack Exchange felhasználóktól? Nézze meg a teljes beszélgetés szálát itt.