Чому я не можу змінити файли, що використовуються у Windows, як я можу на Linux і OS X?

Коли ви використовуєте Linux і OS X, операційна система не завадить вам видалити файл, який наразі використовується в Windows, і вам буде заборонено робити це. Що дає? Чому ви можете редагувати та видаляти файли, що використовуються, у системах з Unix, але не Windows?

Сьогоднішня сесія запитань та відповідей приходить до нас люб'язно SuperUser - підрозділ Stack Exchange, групування веб-сайтів із запитаннями та відповідями на рівні спільноти..

Питання

Читач SuperUser the.midget хоче знати, чому Linux і Windows по-різному ставляться до файлів, що використовуються

Одна з речей, які мене здивували з тих пір, як я почала користуватися Linux, - це те, що вона дозволяє змінювати ім'я файлу або навіть видаляти його під час читання. Наприклад, я випадково спробував видалити відео під час його відтворення. Мені вдалося, і я був здивований, як я дізнався, що ви можете змінити майже все, що є у файлі, не піклуючись, якщо він використовується зараз чи ні.

Отже, що відбувається за лаштунками і заважає йому безпричинно видаляти речі в Windows, як він може в Linux?

Відповідь

Співробітники SuperUser проливають певне світло на ситуацію для the.midget. Здивований пише:

Всякий раз, коли ви відкриваєте або виконуєте файл у Windows, Windows блокує файл на місці (це спрощення, але, як правило, вірно.) Файл, який заблокований процесом, не може бути видалений, поки цей процес не випустить його. Ось чому всякий раз, коли Windows повинна самостійно оновлюватися, потрібна перезавантаження, щоб вона вступила в силу.

З іншого боку, Unix-подібні операційні системи, такі як Linux і Mac OS X, не блокують файл, а скоріше основні сектори диска. Це може здатися тривіальною диференціацією, але це означає, що запис файлу у змісті файлової системи можна видалити, не порушуючи жодної програми, яка вже має відкритий файл. Таким чином, ви можете видалити файл, поки він все ще виконується або іншим чином використовується, і він продовжуватиме існувати на диску, доки певний процес має відкриту ручку для нього, навіть якщо його запис у файловій таблиці не існує..

Девід Шварц розширює ідею і підкреслює, яким чином ідеї повинні бути в ідеалі і як вони на практиці:

За промовчанням Windows встановлюється автоматичне, обов'язкове блокування файлів. UNIX за замовчуванням використовують ручний, кооперативний блокування файлів. В обох випадках типові значення можуть бути перевизначені, але в обох випадках вони зазвичай не є.

Багато старих кодів Windows використовують C / C ++ API (функції, такі як fopen), а не рідний API (функції, такі як CreateFile). API C / C ++ не дає змоги вказати, як буде працювати обов'язкова блокування, тому ви отримаєте значення за замовчуванням. За замовчуванням "режим спільного доступу" має тенденцію до заборони "конфліктуючих" операцій. Якщо ви відкриваєте файл для запису, передбачається, що його записує конфлікт, навіть якщо ви ніколи не записуєтеся у файл. Те ж саме для перейменувань.

І, ось де вона погіршується. Крім відкриття для читання або запису, C / C ++ API не дає можливості вказати, що ви збираєтеся робити з цим файлом. Таким чином, API має припустити, що ви збираєтеся виконувати будь-яку правову операцію. Оскільки блокування обов'язкове, відкриття, яке дозволяє конфліктуючу операцію, буде відхилено, навіть якщо код ніколи не мав наміру виконувати конфліктну операцію, а просто відкривав файл з іншою метою.

Отже, якщо код використовує C / C ++ API, або використовує рідний API, не замислюючись над цими проблемами, вони перестануть запобігати максимальному набору можливих операцій для кожного відкритого файлу і не можуть відкрити файл, якщо всі можливі операції може виконати на ньому раз відкрито не конфліктно.

На мій погляд, метод Windows буде працювати набагато краще, ніж метод UNIX, якщо кожна програма вибирає свої режими спільного використання та відкриті режими мудро і добре обробляє випадки відмови. Метод UNIX, однак, працює краще, якщо код не турбує думати про ці питання. На жаль, базовий C / C ++ API не відображається добре на API файлу Windows таким чином, що обробляє режими спільного доступу та конфліктує добре відкривається. Таким чином, чистий результат трохи розвалений.

У вас є: два різних підходи до обробки файлів дають два різні результати.

Маєте щось додати до пояснення? Звучить в коментарях. Хочете прочитати більше відповідей від інших технологічних користувачів Stack Exchange? Перегляньте повний потік обговорення тут.