Блог GunSmoker-а (переклади) Але чомусь біти називаються FILE_SHARE_READ і FILE_SHARE_WRITE

. коли встановлюють одну версію, як добре, як програмування на комп'ютері, що це означає, що людина.

Але чому біти називаються FILE_SHARE_READ та FILE_SHARE_WRITE?

Пост Реймонда про біти FILE_SHARE_* нагадав мені історію про те, звідки узялися біти типу FILE_SHARE_READ. У MS-DOS була така ж семантика поділу файлів (file sharing semantics) як і в NT (ok, NT додає ще прапор FILE_SHARE_DELETE - докладніше про це пізніше). Але на MS-DOS семантика поділу файлів є опціональною - ви повинні були запустити утиліту share.com, щоб використовувати її. Це пояснюється тим, що на однозадачній операційній системі завжди працює тільки одна програма, тому семантика поділу файлів не потрібна. Якщо ви не використовували файловий сервер - у цьому випадку Microsoft настійно рекомендувала запускати утиліту.

У MS-DOS режим поділу контролювався трьома бітами "режим поділу" ("sharing mode"). Документованими значеннями для "режиму поділу" були:

000– Режим сумісності. Будь-який процес може відкрити файл з цим режимом будь-яку кількість разів. Відкриття файлу буде невдалим, якщо файл вже був відкритий у будь-якому іншому режимі.001– Заборонити все. Відкриття буде невдалим, якщо файл був відкритий в режимі сумісності, читання або запису. Навіть якщо файл був відкритий поточним процесом.010– Заборонити запис. Відкриття буде невдалим, якщо файл був відкритий у режимі сумісності або для запису будь-яким процесом.011– Заборонити читання. Відкриття буде невдалим, якщо файл був відкритий у режимі сумісності або для читання будь-яким процесом.100– Нічого не забороняти. Відкриття буде невдалим, якщо файл був відкритий у режимі сумісності будь-якимпроцесом.

Разом із бітами " режиму поділу " пристиковувалися біти " коду доступу " (“access code”). Для них було лише три законні значення: Читання, Запис та обидва одночасно (Читання/Запис).

Дизайнери набору Win32 API (зокрема, дизайнер підсистеми введення-виводу) щойно глянули на ці прапори - так одразу ж скинули руки в огиді. На його думку, із цими визначеннями є дві великі проблеми:

  1. Через те, що біти поділу визначаються як заперечення чогось, стає дуже складно визначити, що ж у результаті буде дозволено і заборонено. Якщо ви відкриваєте файл для запису в режимі заборони читання: що буде? Як щодо режиму заборони запису – він припускає читання чи ні?
  2. Через те, що режимом за промовчанням є режим “сумісності”, це означає, що за замовчуванням більшість програм не можуть гарантувати узгодженість своїх даних. Замість того, щоб бути захищеним за замовчуванням, вам потрібно робити ще якісь додаткові. дії, щоб гарантувати, що ніхто більше не чіпає ваших даних.
Тому дизайнер підсистеми введення-виведення запропонував інвертувати семантику бітів поділу доступу. Замість того, щоб біти забороняли доступ, вони тепер ДОЗВОЛЯЮТЬ доступ. Замість того, щоб за промовчанням дозволяти доступ, тепер за промовчанням доступ буде заборонено. Додаток потрібно явно вказувати, що він хоче дати доступ до файлу та іншим, поки він працює з ним.

Ця зміна красиво вирішує купу проблем, що існували при одночасному запуску кількох додатків MS-DOS - якщо одна програма працювала; Інша програма могла потай зіпсувати дані, з якими працювала перша.

Отже, ми можемо пояснити, що прапори FILE_SHARE_READ та FILE_SHARE_WRITE є більш зрозумілими та безпечними.версією дозволів доступу DOS. Але що про FILE_SHARE_DELETE? Звідки, чорт забирай, він узявся? Ну, він був доданий до Posix-сумісності. У підсистемі Posix, так само, як і *nix, файл може бути видалений (unlinked), поки він все ще відкритий. Крім того, коли ви перейменуєте файл у NT, операція перейменування відкриває вихідний файл для доступу видалення (врешті-решт операція перейменування - це створення нового файлу в каталозі-призначенні та видаленні файлу зі старого місця).

Але програми DOS не очікують, що файли можуть бути видалені (або перейменовані), поки вони з ними працюють - так що нам треба мати якийсь механізм, щоб заборонити системі видаляти (або перейменовувати) файл, якщо це важливо. Ось тут на сцену і виходить додатковий біт FILE_SHARE_DELETE – це прапор, який каже системі: "нічого страшного, якщо хтось захоче видалити або перейменувати цей файл, доки я з ним працюю".