Блокування виконуваних файлів: Windows робить, Linux - ні. Чому?

Я помітив, що коли файл виконується у Windows (.exe або .dll), він заблокований і не може бути видалений, переміщений або змінений.

Linux, навпаки, не блокує виконувані файли, і ви можете їх видалити, перемістити або змінити.

Чому Windows блокується, коли Linux цього не робить? Чи є перевага блокування?

Linux має механізм підрахунку посилань, тому ви можете видалити файл під час його виконання, і він буде продовжувати існувати до тих пір, поки певний процес (який раніше його відкривав) має відкритий дескриптор для нього. Запис каталогу для файлу видаляється під час його видалення, тому його більше не можна відкривати, але процеси, які вже використовують цей файл, все ще можуть його використовувати. Після завершення всіх процесів, що використовують цей файл, файл автоматично видаляється.

Windows не має цієї можливості, тому вона змушена блокувати файл, поки не будуть завершені всі процеси, що виконуються з нього.

Я вважаю, що поведінка Linux є кращою. Можливо, є кілька глибоких архітектурних причин, але головною (і простою) причиною, яку я вважаю найбільш переконливою, є те, що в Windows іноді не вдається видалити файл, ви навіть не уявляєте, чому, і все, що вам відомо, це те, що якийсь процес тримає його використання. У Linux це ніколи не відбувається.

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

Програми Unix весь час використовують такий спосіб думки про файлову систему, створюють тимчасовий файл, відкривають його, видаляють ім'я. Ваш файл все ще існує, але ім'я звільнено для використання іншими, і ніхто інший його не може бачити.

Linux дійсно блокує файли. Якщо ви спробуєте перезаписати файл, який виконується, ви отримаєте "ETXTBUSY" (Текстовий файл зайнятий). Однак ви можете видалити файл, і ядро ​​видалить файл, коли буде видалено останнє посилання на нього. (Якщо машина не була чисто вимкнена, ці файли є причиною повідомлень "Видалений inode мав нульовий час", коли перевіряється файлова система, вони не були повністю видалені, оскільки запущений процес мав посилання на них, і зараз вони є.)

Це має кілька основних переваг, ви можете оновити процес, який працює, видаливши виконуваний файл, замінивши його, а потім перезапустивши процес. Навіть init можна оновити таким чином, замінити виконуваний файл і надіслати йому сигнал, і він повторно виконає () сам, не вимагаючи перезавантаження. (Це зазвичай робиться автоматично вашою системою управління пакетами в рамках оновлення)

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

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

Ви також можете використовувати цей трюк під Linux для тимчасових файлів. відкрийте файл, видаліть його, а потім продовжуйте використовувати файл. Коли ваш процес завершиться (незалежно від причини - навіть відключення живлення), файл буде видалено.

Програми, такі як lsof та fuser (або просто тикання в / proc // fd), можуть показати вам, у яких процесах відкриваються файли, які більше не мають імені.

Я думаю, що linux / unix не використовує однакові механіки блокування, оскільки вони побудовані з нуля як багатокористувацька система - що очікує можливості того, що кілька користувачів використовують один і той же файл, можливо, навіть для різних цілей.

Чи є перевага блокування? Ну, це може, можливо, зменшити кількість покажчиків, якими ОС повинна була б керувати, але зараз кількість заощаджень досить незначна. Найбільша перевага, яку я можу придумати перед блокуванням, полягає в наступному: ви економите деяку невизначеність, яку можна переглянути. Якщо користувач a запускає двійковий файл, а користувач b видаляє його, тоді фактичний файл повинен залишатися, поки процес користувача A не завершиться. Однак, якщо користувач B або будь-який інший користувач шукає файлову систему, він не зможе його знайти, але він і надалі займе місце. Мене насправді не дуже турбує.

Я думаю, що в основному це більше питання про зворотну сумісність з файловими системами вікна.

Я думаю, ти занадто абсолютний щодо Windows. Зазвичай він не виділяє простір підкачки для кодової частини виконуваного файлу. Натомість він тримає замок на виконуваних файлах та бібліотеках DLL. Якщо відкинуті кодові сторінки потрібні знову, вони просто перезавантажуються. Але з / SWAPRUN ці сторінки зберігаються в місцях обміну. Це використовується для виконуваних файлів на компакт-дисках або мережевих дисках. Отже, Windows не потребує блокування цих файлів.

Для .NET подивіться на Тіньова копія .

Якщо виконаний код у файлі повинен бути заблокований чи ні - це рішення проекту, і MS просто вирішила заблокувати, оскільки це має очевидні переваги на практиці: Таким чином, вам не потрібно знати, який код у якій версії використовується яким додатком. Це головна проблема поведінки за замовчуванням Linux, яку більшість людей просто ігнорує. Якщо загальносистемні бібліотеки замінено, ви не зможете легко дізнатись, які програми використовують код таких бібліотек. Найчастіше найкраще, що ви можете отримати, - це те, що менеджер пакетів знає деяких користувачів цих бібліотек і перезапускає їх. Але це працює лише для загальних і добре відомих речей, таких як, можливо, Postgres та його бібліотеки чи подібні. Більш цікаві сценарії, якщо ви розробляєте свій власний додаток для деяких сторонніх бібліотек, і їх замінюють, оскільки більшість випадків менеджер пакунків просто не знає вашого додатка. І це ' Це проблема не тільки власного коду C або подібного, це може трапитися майже з усім: просто використовуйте httpd з mod_perl та деякими бібліотеками Perl, встановленими за допомогою менеджера пакунків, і нехай менеджер пакетів оновлює ці бібліотеки Perl з будь-якої причини. Він не перезапустить ваш httpd, просто тому, що не знає залежностей. Існує безліч прикладів, подібних до цього, просто тому, що будь-який файл потенційно може містити код, який використовується в пам’яті будь-яким середовищем виконання, подумайте про Java, Python та всі подібні речі.

Тож є вагома причина думати, що блокування файлів за замовчуванням може бути хорошим вибором. Однак вам не потрібно погоджуватися з цими причинами.

То що зробив РС? Вони просто створили API, який надає програмі, що викликає, можливість вирішити, чи слід блокувати файли чи ні, але вони вирішили, що значення цього API за замовчуванням полягає у забезпеченні ексклюзивного блокування для першої програми, що викликає. Погляньте на API навколо CreateFile та його dwShareModeаргументи. Саме тому у вас може не бути можливості видалити файли, що використовуються якимось додатком, він просто не дбає про ваш варіант використання, використовував значення за замовчуванням і, отже, отримав ексклюзивне блокування Windows для файлу.

Будь ласка, не вірте тим, що люди, які говорять вам щось про Windows, не використовують перерахування посилань на HANDLE або не підтримують жорсткі посилання або подібні, що є абсолютно неправильним. Майже кожен API, який використовує HANDLEs, документує свою поведінку щодо підрахунку реф., І ви можете легко прочитати майже в будь-якій статті про NTFS, що він фактично підтримує жорсткі посилання і завжди. Починаючи з Windows Vista, він також підтримує символічні посилання, а підтримку твердих посилань покращено завдяки наданню API для зчитування всіх даних для певного файлу тощо.

Крім того, ви можете просто захотіти поглянути на структури, що використовуються для опису файлу, наприклад, у Ext4, порівняно із структурами NTFS , які мають багато спільного. Обидва вони працюють з концепцією extents, яка відокремлює дані від таких атрибутів, як ім'я файлу, а inodes - це в основному просто інша назва для більш старої, але подібної концепції цього. Навіть Вікіпедія перераховує обидві файлові системи у своїй статті .

Насправді багато FUD щодо блокування файлів у Windows, порівняно з іншими ОС в мережі, як і дефрагментація. Дещо з цього FUD можна виключити, просто прочитавши трохи у Вікіпедії .

Варіанти NT мають

openfiles

команда, яка покаже, які процеси мають дескриптори на яких файлах. Однак для цього потрібно ввімкнути глобальний прапор системи `` підтримувати список об'єктів ''

openfiles / local /?

розповідає, як це зробити, а також про те, що за це стягується штраф за виконання.

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