Блогът на GunSmoker (преводи) Но защо битовете се наричат FILE_SHARE_READ и FILE_SHARE_WRITE
. когато промяната на съзнанието става толкова лесна, колкото програмирането на компютър, какво означава да си човек.
Но защо битовете се наричат FILE_SHARE_READ и FILE_SHARE_WRITE?
Постът на Реймънд за битовете FILE_SHARE_* ми напомни историята за това откъде идват битовете FILE_SHARE_READ на първо място. MS-DOS имаше същата семантика за споделяне на файлове като NT (добре, NT добавя още един флаг FILE_SHARE_DELETE - повече за това по-късно). Но в MS-DOS семантиката за споделяне на файлове не е задължителна - трябваше да стартирате помощната програма share.com, за да я използвате. Това е така, защото само едно приложение винаги работи на еднозадачна операционна система, така че не е необходима семантика за разделяне на файлове. Освен ако не използвате файлов сървър, в който случай Microsoft силно препоръчва да стартирате помощната програма.
В MS-DOS режимът на споделяне се управляваше от три бита "режим на споделяне". Документираните стойности за "разделен режим" бяха:
000– Режим на съвместимост. Всеки процес може да отвори файл с този режим произволен брой пъти. Отварянето на файла ще бъде неуспешно, ако файлът вече е бил отворен в друг режим.001- Отказ на всичко. Отварянето ще бъде неуспешно, ако файлът е бил отворен в режим на съвместимост, за четене или за запис. Дори ако файлът е отворен от същия процес.010- Отказ на писане. Отварянето ще бъде неуспешно, ако файлът е бил отворен в режим на съвместимост или за запис от който и да е процес.011- Отказ на четене. Отварянето ще бъде неуспешно, ако файлът е бил отворен в режим на съвместимост или четен от който и да е процес.100- Не отказвайте нищо. Отварянето ще бъде неуспешно, ако файлът е бил отворен в режим на съвместимост от някойпроцес.
Битовете "код за достъп" бяха закачени заедно с битовете "споделен режим". За тях имаше само три легитимни стойности: Четене, Писане и двете наведнъж (Четене / Писане).
Дизайнерите на набора Win32 API (по-специално дизайнерът на I/O подсистемата) погледнаха тези флагове и вдигнаха ръце с отвращение. Според него има два големи проблема с тези определения:
- Тъй като разделителните битове се определят като отричане на нещо, става много трудно да се определи какво ще бъде разрешено и забранено в крайна сметка. Ако отворите файл за запис в режим на отказ за четене: какво се случва? Какво ще кажете за режима без запис - чете ли се или не?
- Тъй като режимът по подразбиране е „съвместимост“, това означава, че по подразбиране повечето приложения не могат да гарантират последователността на своите данни. Вместо да сте защитени по подразбиране, трябва да направите някои допълнителни неща. действия, за да гарантирате, че никой друг не докосва вашите данни.
Тази промяна прекрасно решава куп проблеми, които съществуват при стартиране на множество MS-DOS приложения едновременно - ако едно приложение работи; друго приложение може тихо да повреди данните, с които е работило първото.
Така че можем да обясним, че флаговете FILE_SHARE_READ и FILE_SHARE_WRITE са по-ясни и по-безопасниверсия на правата за достъп на DOS. Но какво да кажем за FILE_SHARE_DELETE? Откъде, по дяволите, се е появил? Е, беше добавено за съвместимост с Posix. В подсистемата Posix, точно както в *nix, даден файл може да бъде изтрит (несвързан), докато е все още отворен. Освен това, когато преименувате файл в NT, операцията за преименуване отваря оригиналния файл за достъп за изтриване (в края на краищата операцията за преименуване е свързана със създаването на нов файл в целевата директория и изтриването на файла от старото местоположение).
Но DOS приложенията не очакват файловете да бъдат изтрити (или преименувани), докато работят с тях - така че се нуждаем от някакъв механизъм, който да попречи на системата да изтрие (или преименува) файл, ако приложението го е грижа. Тук влиза в действие допълнителният бит FILE_SHARE_DELETE - това е флаг, който казва на системата: „добре е, ако някой иска да изтрие или преименува този файл, докато работя с него.“